Verify Criteria Prompt Patterns for Self-Checking Agents

Verify criteria prompting turns “done” into something a self-checking agent can prove: a command exit code, a schema check, a file assertion, or a graded checklist with binary outcomes. You write those checks into the loop brief so the worker cannot declare victory from its own summary. This page catalogs patterns for measurable criteria, verification ladders, negative checks, maker-checker wording, and paste-ready examples for Claude Code /goal style work as of mid-2026. PromptMake at https://promptmake.net/loop-prompt-generator writes command text only. It does not run loops or grade your repo. Turn-cap sizing lives in the companion turn-cap article. Stay here for the evidence side of the contract.

What verify criteria are and who needs them

Verify criteria are the observable proofs an agent must collect before claiming success. Strong lines name a command, expected signal, and any protected behavior. Weak lines ask for quality vibes: “make it robust,” “ensure UX feels good,” “fix everything.”

Self-checking agents fail in a predictable way. They just produced the change, so they hold a strong prior that the change is correct. Subjective stop language invites early victory. Machine-checkable or checklist-binary language fights that bias.

Who needs this craft: engineers running Claude Code loops on tickets, teams writing reusable loop templates, and anyone adapting Codex or Cursor agents to the same goal-verify-cap shape. Skills (SKILL.md) teach standing workflows. Verify criteria belong on the one-job loop brief.

PromptMake expands a plain task into success criteria, turn cap, verification steps, and stop guidance. Soft start: https://promptmake.net/loop-prompt-generator. Review every path and command before paste.

Three tests every criterion must pass

Verifiable: something can confirm it (command, count, schema, second model with a binary checklist). Falsifiable: it can fail with a clear signal. Cheap enough: you can afford to run it every turn or at least every cycle. Criteria that fail these tests are goals in disguise.

Self-check versus external evidence

Self-check means the worker runs the proof and surfaces output in the transcript. External evidence means tests, lint, builds, HTTP status, or a separate checker model that grades without fixing. Prefer external evidence. When you must use an LLM checker, force structured PASS/FAIL with named fields, not open judgment.

Pattern library for verify criteria prompting

Build a small library of patterns your team reuses. Swap paths and package managers; keep the shape. Soft drafting for full command blocks: https://promptmake.net/loop-prompt-generator.

Pattern A — exit code gate: npm test -- workspace packages/auth exits 0. Pattern B — empty output gate: rg "FIXME_BLOCKER" src returns no matches. Pattern C — file existence: packages/api/src/health.ts exists and exports healthHandler. Pattern D — negative scope: git status --porcelain only lists paths under packages/api. Pattern E — HTTP probe: curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/health prints 200. Pattern F — schema: npx tsc -p packages/api --noEmit exits 0.

Combine with AND semantics in one finish line when all must hold. Split into separate loops when proofs fight each other or take too long. Document which pattern class each recurring ticket uses.

As of mid-2026, Claude Code /goal evaluators judge from conversation evidence. Require the worker to print command results. The evaluator does not independently invent shell access beyond what the worker exposes.

Binary checklist pattern for LLM graders

When a second model grades, give it a closed list: PASS only if (1) named test command exits 0, (2) named lint exits 0, (3) diff stays inside listed paths. FAIL with the first broken line. Forbid the grader from proposing fixes. That maker-checker split cuts self-grading bias.

Negative verify pattern

Positive greens hide regressions. Add negative lines: no new eslint-disable, no lockfile churn outside the bump ticket, no migration files, no deleted config. Abort when negatives trip even if tests are green.

Build a verification ladder step by step

A verification ladder orders checks from fast and narrow to broad and expensive. Early failures burn fewer tokens. Late expensive builds only run when cheap gates already pass. Write the ladder as numbered steps in the brief so the agent cannot skip to “full suite” on turn one.

Step 1: single failing spec or targeted unit file. Step 2: package or workspace tests. Step 3: lint or typecheck on touched paths. Step 4: production build if the change can break bundling. Step 5: diff review against scope fences. State expected exit codes and forbidden side effects on each step.

Abort early when step 1 fails three times with the same fingerprint, when credentials are missing, or when step 5 shows out-of-scope paths. Pair the ladder with a turn cap from the companion article so impossible ladders still stop.

Guest free use on PromptMake: about three loop generations per day. Free registered accounts: about five. Anthropic spend is separate.

Ladder example: auth bugfix

1) npm test -- auth.spec.ts exits 0. 2) npm test --workspace packages/auth exits 0. 3) lint touched files clean. 4) no files outside packages/auth. On any fail: fix within scope or escalate. Do not claim done until all four pass.

Ladder example: docs sync

1) every CLI flag in bin/cli.ts appears in docs/install.md. 2) rg for each flag name returns a hit in docs. 3) no edits outside those two paths. Skip full product test suites unless docs generation is tied to a build step you name.

Maker-checker and self-report patterns

Maker-checker separates “do” from “grade.” The maker edits and runs tools. The checker only evaluates evidence. In Claude Code /goal flows, a separate evaluator model often grades the condition each turn. Your prompt must still demand that the maker surfaces raw command output.

Self-report patterns ask the worker to fill a fixed report block every cycle: commands run, exit codes, files touched, remaining risks. The report is input to the checker, not a substitute for exit codes. Ban “I am confident tests would pass” language.

For hosts without a native evaluator, paste a checker paragraph that runs after each edit cycle: run the ladder, print PASS/FAIL per line, stop edits on FAIL after N retries. Soft structure help: https://promptmake.net/loop-prompt-generator.

High-risk domains need a human as the final checker: payments, permissions, production data. Use turn-based cycles and require your explicit continue after the self-check report.

Paste block: worker self-report

After each cycle output: Commands (name + exit code), Diff paths, Verify ladder results (pass/fail per step), Blockers, Next action. Do not claim success unless every ladder step is pass.

Paste block: checker-only role

You verify. You do not fix. Run the listed check commands. Reply only with PASS or FAIL and the first failing line. No refactor suggestions in the same turn.

Paste-ready verify blocks by job type

Copy these blocks into a /goal condition or turn-based brief. Swap package managers and paths. Keep the binary shape. Soft polish at https://promptmake.net/loop-prompt-generator when you want the full command wrapper with turn cap and abort lines filled in.

Bugfix block: Goal restates the failing test name. Verify: (1) npm test -- path/to/failing.spec.ts exits 0, (2) npm test --workspace packages/X exits 0, (3) git status --porcelain only lists paths under packages/X, (4) no new eslint-disable in the diff. Report each line as pass or fail with the last ten lines of failing output.

Docs sync block: Verify: (1) every public flag string in bin/cli.ts appears in docs/install.md, (2) rg -n "--flag-name" docs/install.md hits for each flag you list in the goal, (3) no files outside bin/cli.ts and docs/install.md change. Skip product test suites unless you name a docs build step the agent can run.

Dependency bump block: Verify: (1) only the named package version changed in the lockfile, (2) npm test --workspace packages/web exits 0, (3) npm run build --workspace packages/web exits 0, (4) abort if any other dependency version shifts. Print npm ls named-package before and after.

API contract block: Verify: (1) OpenAPI or zod schema check exits 0, (2) contract tests for the touched route exit 0, (3) response sample includes required fields named in the goal, (4) no migration files appear unless the goal named them. Prefer schema tools over “looks compatible” prose.

Flaky quarantine block: Verify: either the named spec passes three consecutive runs, or it is skipped with an issue URL in the skip reason. Print all three run excerpts. Do not delete the spec. Do not broaden to unrelated flakes in the same loop.

Store winning blocks under docs/agent-loops/verify/ with the host version and date. When Claude Code slash fields move, retest the same block before you trust unattended runs.

Aligning verify text with the goal sentence

Read the goal and the verify list aloud. If the goal promises a public API change but verify only runs unit tests, add an export or typecheck line. If the goal promises docs sync but verify runs the full monorepo suite, cut the suite. Mismatch is a common false-completion source.

When evidence cannot be collected

Write abort criteria for missing secrets, downed services, and sandboxes that block the verify command. On abort, the agent prints what it tried and stops edits. Silent retries without evidence waste the turn budget you set in the companion turn-cap article.

Common verify criteria mistakes

Mistake 1: Subjective finish lines.

Mistake 2: Criteria the agent cannot run because the command is missing or the env lacks secrets.

Mistake 3: Full monorepo suite as step 1.

Mistake 4: No negative scope checks.

Mistake 5: Checker allowed to edit.

Mistake 6: Verify wording that disagrees with the goal sentence.

Mistake 7: Treating PromptMake output as executed proof.

Mistake 8: Confusing this page with the turn-cap article; they are complementary halves of one contract.

Soft next steps

Take one failing ticket. Write three verifiable lines and one negative line. Order them cheap to expensive. Generate a polished loop brief at https://promptmake.net/loop-prompt-generator if you want structure. Paste into Claude Code on a branch. Compare false-completion rate against your last unbounded run.

FAQ

What is verify criteria prompting?

Verify criteria prompting is the craft of writing measurable proof lines into an agent brief so self-checking agents stop on evidence, not vibes. You name commands, expected signals, and protected behavior. Soft drafts: https://promptmake.net/loop-prompt-generator.

How do verify criteria differ from turn caps?

Verify criteria define success. Turn caps define when to stop without success. You need both. This page deepens verify patterns. The turn-cap article deepens cost and scope ceilings. Together they form a full loop contract.

What makes a good verify line for Claude Code?

A good line is binary, runnable, and cheap enough to repeat: test exit codes, lint output, grep emptiness, path-limited git status. Weak lines ask for subjective quality. Order cheap checks first. Include negative checks when regressions hide behind green tests.

Should the same model make and check?

Prefer a split. Workers over-trust their own edits. Use a separate evaluator, a Stop hook style gate, or at least a rigid PASS/FAIL checklist that forbids fixing in the same breath. Always require printed command evidence in the transcript.

Can verify criteria include HTTP or schema checks?

Yes when the agent can reach the endpoint or run the schema tool in your environment. Name the exact curl, migrate dry-run, or tsc --noEmit command. Abort early if the service is down instead of inventing stubs.

Does PromptMake run my verify commands?

No. https://promptmake.net/loop-prompt-generator returns text: recommended primitive, success criteria, turn cap, verification steps, and stop guidance. You paste into Claude Code or Codex. Guests get about three generations per day; free registered accounts about five.

How do I start today?

Pick one ticket with a clear test command. Write Pattern A plus one negative scope line. Add a conservative turn cap. Run supervised on a branch. Save the winning ladder under docs/agent-loops/ with the date and host version.