Prompt Engineering & Output Quality

Prompting Claude to Critique Its Own Output

"Now review what you just wrote against these criteria" is one of the simplest quality levers available — and one of the easiest to overuse. Here's where self-critique earns its cost, and where it doesn't.

Claude 3P 101 · Updated July 2026 · Unofficial guide

A self-critique loop asks the model to produce a draft, then — in a follow-up turn or a second call — evaluate that draft against explicit criteria and revise it. It works for the same reason human editing works: reviewing a finished draft is a different, easier task than writing one, and errors that slipped through generation are often obvious on re-read. But every critique pass is another model call with the draft in context, so it roughly doubles cost and latency per pass. The engineering question is not "does it help?" but "does it help more than the same tokens spent elsewhere?"

The basic pattern

Anthropic's best-practices reference includes prompt chaining — breaking complex work into sequential prompts — among its core techniques, and self-critique is the simplest chain: generate, evaluate, revise. Two design rules make the difference between a real review and a rubber stamp.

Criteria must be concrete and checkable. "Review your answer for quality" produces "On review, the answer looks good." Instead, enumerate: every claim traceable to the source document; all requested fields present; no numbers that don't appear in the input; under 200 words. Specific criteria give the critique something to fail.

Separate the verdict from the rewrite. Ask for a structured verdict first (a list of specific violations, or "PASS"), then revise only if violations were found. This lets your code skip the third call when the draft passes, and gives you a log of what the critique actually catches — which you'll want later.

from anthropic import AnthropicAWS  # Claude Platform on AWS

client = AnthropicAWS()
draft = client.messages.create(model="claude-sonnet-5", max_tokens=1024,
    messages=[{"role": "user", "content": task}])
review = client.messages.create(model="claude-sonnet-5", max_tokens=1024,
    messages=[{"role": "user", "content":
        f"{draft.content[0].text}\n"
        "List each violation of these criteria, or reply PASS:\n"
        f"{CRITERIA}"}])
if "PASS" not in review.content[0].text:
    pass  # third call: revise the draft using the violations

A fresh second call — rather than continuing the same conversation — often critiques more honestly: the model isn't anchored on its own reasoning, and you can frame it as reviewing "a draft" rather than "your draft."

When self-critique adds value

Checkable, high-stakes outputs. Grounded summaries, extraction from contracts, customer-facing drafts — tasks where criteria like "every figure appears in the source" can be verified by re-reading. This is where critique catches real errors.

Long outputs with mechanical requirements. Reports that must include specific sections, cover every input item, or respect length limits. Drift on these is common in generation and easy to spot in review.

As the judge in your eval pipeline. The same critique prompt that reviews drafts in production can grade outputs in your test harness — one rubric, two uses (see building an evaluation framework).

When it doesn't

Facts the model can't check from context. If the draft's claim isn't verifiable from material in the prompt, the critique is guessing too. Self-critique verifies internal consistency and criteria compliance, not ground truth — retrieval or citations solve that problem instead.

Where cheaper mechanisms already exist. Schema compliance is guaranteed by structured outputs; deterministic checks (length, required fields, banned phrases) belong in ordinary code, which is free. Reserve model-based critique for judgments code can't make.

On models already reasoning deeply. Current models with adaptive thinking already deliberate before answering — Anthropic's docs note thinking depth is promptable with phrases like "Please think hard before responding," and the effort parameter raises thoroughness within a single call. Try one careful call at higher effort before architecting a two-call loop; measure both against your eval set and keep the cheaper one that passes.

Rule of thumb: add a critique pass when a named failure mode appears in your eval results and the critique demonstrably catches it. If the critique log is all PASS, delete the pass and bank the savings.

Cap the loop

Never let critique-revise cycle unbounded — passes beyond the first or second yield sharply diminishing returns while doubling cost each time. Cap at one revision, log verdicts, and route drafts that still fail to a human instead of a third rewrite (graceful escalation).

Where to go next

See review patterns for critique prompts in detail, task decomposition for larger chains, and extended thinking for the single-call alternative.

Sources