Skills With a Built-In Verdict — The Ones That Can Say No
Ask a skill to make something and it makes something. Ask the best ones and they sometimes refuse. That refusal — a skill with a standard it enforces against itself — turns out to be one of the strongest signals in our scoring data.
Here's a dimension nobody optimizes on purpose: can this skill reject its own work? Most skills are pure producers — prompted to draft, they draft; prompted to generate, they generate; the output exists, therefore it ships. A smaller class encodes a standard and checks against it, which means the skill has a failure mode that isn't "produced nothing."
We went looking for this class across the directory. It's small — maybe fifteen skills — and its average score is a full point above the directory mean.
The three verdict types
Type 1: The auditor. code-reviewer — 9.4
Analyzes diffs and files for bugs and security vulnerabilities. Its entire output is a verdict — but the design detail that earns the score is that "no findings" is a valid, structured result. The skill doesn't invent problems to justify its existence; it defines what passes.
Type 2: The gatekeeper. vercel-optimize — 9.4
Performance analysis with severity-ranked findings. Same property: the skill states what "already fast enough" means, and a report that comes back empty is a successful run. Producer skills can't do this — an empty output is failure by definition.
Type 3: The self-checking producer. anatomy — 9.5
Builds interactive isometric SVG figures — a producer! — but its contract includes validation: the figure must be inspectable, well-formed, and pass its own detail standard before delivery. The skill describes what a rejected draft looks like and how to fix one. That's the pattern: production plus an internal bar.
The same shape shows up in baoyu-electron-extract (9.5 — extraction with a manifest the agent verifies), replica-test (9.1 — a test run that can fail the replication), and archify (9.4 — "polished, validated" architecture diagrams, where validated is doing real work).
Why verdicts score so well
Two of our six dimensions are directly about this:
Workflow design — the second-strongest score predictor — rewards skills with a defined done-state. A skill that can say no has the most rigorous done-state possible: output that meets a written standard, checked before delivery.
Content quality rewards specificity. A standard precise enough to reject against forces the author to write down what good means, in checkable terms. The checkable contract is exactly what separates 9s from 8s in our methodology.
There's also a trust effect we can't score but can observe: verdict skills are the safest class in the directory. A skill that holds itself to a standard is a skill that has thought about failure — which correlates strongly with the security-mindedness we check for in every evaluation.
How to write one
The recipe, distilled from the five best:
- Define pass before you define produce. "This is done and acceptable when ___" — write that sentence first. If you can't fill the blank, you have a producer, and that's fine, but know it.
- Make "no findings" a first-class output. Empty-with-structure, not empty-as-failure. The auditor skills all do this; it's what keeps them honest.
- **Reject before delivery, not after.** The self-checking producers validate drafts internally; the user never sees a rejected artifact. The rejection is a step, not an apology.
- Write the rejection criteria down. A verdict you can't read is a verdict the agent won't apply. The criteria belong in the SKILL.md, where they double as the quality bar.
The test for any skill you're writing: when would this skill refuse to ship its own output? If the answer is "never," you've built a producer — useful, but you've left a point on the table. If the answer is a sentence you can quote, you've built a verdict, and the scores in this class suggest you're done.
Where to browse
The verdict skills cluster in developer tools — reviewers, testers, analyzers. For how we score the dimensions they win on, see the methodology page; for the adversarial side of evaluation, our injection-testing writeup shows what testing a skill's standard actually looks like.