---
name: verifier-author
description: >
  Write a checker that can actually fail: mechanical failure conditions, evidence in
  the output, and a deliberately broken test case proving it catches what it claims
  to. Use when an agent keeps approving its own work, when a review step always
  passes, or when adding verification to an existing loop or workflow.
license: MIT
---

# verifier-author

Write the second agent: the one that grades the first and can fail it.

## Why this is separate

A model that produced work is the worst judge of that work. It will report the claims
are sourced and the job is done, because that is what it was trying to produce. The
verifier exists to break that loop, and it only works if it can return FAIL.

A checker that has never failed has not been tested, and an untested checker is worse
than none: it manufactures confidence.

## Rules

### Run in a fresh session

Never ask the session that did the work to check the work. It sees its own reasoning
and grades the intent rather than the output. Give a new session the spec and the
artifacts, and nothing about how they came to be.

### Check facts, counts, and boundaries

- **Facts.** Does every number appear in the source it names? Does every link resolve?
  Did a value change that should not have?
- **Counts.** Is every input item present in the output? Are there as many sections as
  required?
- **Boundaries.** Did the work touch anything outside its brief? Did a drafts-only
  process acquire a send path?

### Never check taste

If a check requires an opinion, it does not belong here. Clarity, persuasiveness and
quality are for the human gate. A model asked to judge them will approve.

### Write failure conditions, not success criteria

```
FAIL if any number in the diff does not appear in <source> with a citation.
FAIL if any existing value changed.
FAIL if any item in <input-list> is missing from the output.
FAIL if the diff touches a file outside <scope>.
Otherwise PASS. Print the verdict and, on FAIL, the condition and the evidence.
```

Listing failures forces specificity, and makes the output actionable: the reader
learns which check failed and why.

### Print evidence, not just a verdict

Bad: `FAIL`

Good: `FAIL: claims check. The diff asserts "38 percent faster" and the claims file
has no entry for it. Line 41.`

## The test that makes it real

Do this once, when you write the checker. It takes five minutes.

1. **Break the work deliberately.** Take a good output and introduce exactly the
   failure this verifier should catch: change a value, delete a required section, add
   an unsourced claim.
2. **Run the verifier.** It must FAIL and it must name what you broke.
3. **If it passes, the verifier is broken.** Fix it and repeat.

Keep the broken version. When the loop changes later, re-confirm the checker still
catches it.

## What a verifier cannot do

It cannot tell you the work was worth doing, and it cannot catch a well-sourced,
plausible, entirely wrong argument. Those reach the human gate, which is the correct
division of labour: mechanical errors are eliminated so judgment is spent where only
judgment works.

## Reference

Every loop here ships a verifier prompt you can read:
https://vibemarketers.ai/loops

A worked walkthrough, including a checker that failed its first test:
https://vibemarketers.ai/guides/how-to-write-a-verifier