How Do You Add a Quality Check Between Claude Prompts?
Add a step that tests the output against stated criteria before anything moves on. Use code for anything code can check, and use a separate Claude call for anything needing judgment. The reviewer should get the criteria and the output, but not the conversation that produced it.
You're checking this output. You didn't write it, and you have no stake in it. Criteria: 1. [testable criterion] 2. [testable criterion] 3. [testable criterion] Source material, for checking facts: [paste] Output to check: [paste] For each criterion, return PASS or FAIL with a quote as evidence. Only report problems that break a criterion. Skip style preferences. End with one line: PROCEED, or FIX, followed by the single most important correction.
- 1Generate a draft
- 2Review against criteria
- 3Refine from the review
Try it now
- 1Take something Claude wrote for you, and write three criteria it has to meet.
- 2Open a new chat, so the reviewer can't see the original conversation, and paste the prompt above.
- 3Check one PASS and one FAIL yourself against the source.
- 4You'll know it's a useful check if it caught something real, or if you trust it enough to skip your own read. If it flags style, tighten the criteria.
Use it when
Use it before anything expensive or hard to undo: before a long draft is generated from an outline, before a batch runs on 10,000 items, before a customer email is sent, or before code is merged.
Skip it when
Skip it if you'll read the output carefully yourself and the step can't do harm. Don't add a Claude reviewer where a simple rule works. A word count or schema check needs code, not a model, and on Opus 5 Anthropic says extra verification instructions add tokens and latency.
Why it works
Anthropic's prompting guide names self-correction as the most common chaining pattern: generate a draft, review it against criteria, then refine from the review. Its agent guide calls programmatic checks between steps "gates". Claude Code's docs explain why a fresh reviewer helps: it hasn't seen your reasoning. They also warn the other way, that a reviewer asked to find problems will always find something, and fixing every finding leaves you with extra layers and tests for cases that can't happen. So tell it what counts.
Example
You produce product descriptions from a spec sheet. Code checks that each is under 80 words and names the model number. A Claude review step then gets the spec and the description, and checks that every number in the description appears in the spec. A wrong voltage gets a FAIL with a quote, and only that one item goes back for a fix.
Going further
Set a limit on retries. Rule of thumb, not a vendor figure: fix once or twice, then send it to a person, since looping can make a reviewer and writer chase each other. Anthropic's evaluator-optimizer pattern works best when criteria are clear and refinement measurably helps. In Claude Code, write review prompts like the docs' example, ending in report gaps that affect correctness and skip style. For unattended runs, you can enforce a check with a Stop hook, so "done" means the command passed, not that Claude says so.
Common mistakes
- Having the same conversation review its own work, where it can see its reasoning and is likely to agree with it.
- Asking "is this good?" A vague question gets a vague answer. Give criteria that can fail.
- Using a model to count words or validate JSON, when a few lines of code are exact and free.
- Fixing every finding from a review. Anthropic warns this can add needless complexity.
Sources
- Prompting best practices, Claude Platform Docs
- Building effective agents, Anthropic Engineering
- Best practices, Claude Code Docs
Checked 6 November 2026. Products change often, so confirm details with the vendor.