Prompt Engineering & Output Quality

Prompt Patterns for Document Review and Critique

Generation gets the headlines, but for many enterprises the safer, higher-value job is the opposite: hand Claude a finished document and ask what's wrong with it.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Review work — checking a contract against a playbook, scoring an RFP response, comparing two vendor proposals — suits Claude unusually well, because the ground truth stays in human hands. Claude flags; a person decides. But evaluation prompts fail differently from generation prompts: the default failure mode is a review that is polite, generic, and agreeable. The patterns below are about forcing specificity.

Give the reviewer a rubric, not a vibe

"Review this document" produces the LLM equivalent of "looks good, a few small suggestions." The fix is to make criteria explicit and force a verdict per criterion. Anthropic's core guidance — be clear and direct, as if briefing a capable new employee — applies doubly to review, where the interesting output is disagreement:

Structure: document on top, rubric at the bottom

Review inputs are long, so the long-context rules apply. Per Anthropic's best practices, put the document at the top of the prompt and the instructions and rubric at the end — placing the query after long content can improve response quality by up to 30%. For comparisons, wrap each document in its own <document> tag with <document_content> and <source> subtags, then reference them by name in the rubric ("for each criterion, state which of proposal_a or proposal_b is stronger and why").

For evidence you can verify, enable citations on the document block ("citations": {"enabled": true}). Claude then returns findings with a structured cited_text field tied to a location — character ranges for plain text, page locations for PDFs — instead of paraphrased recollections. Per the docs, cited text doesn't count toward output tokens, and it removes the "did the contract really say that?" round-trip. One constraint to plan around: citations cannot be combined with structured outputs in the same request (it returns a 400 error), so pick per call — cited prose findings, or schema-shaped scores with quotes as ordinary string fields.

Make scores machine-readable when they feed a process

If review results land in a spreadsheet or trigger a workflow, don't parse prose — request the scorecard via structured outputs (output_config with a JSON schema listing each criterion, verdict, and evidence string). Schema-constrained scoring also suppresses the classic reviewer drift where criteria are skipped or renamed between runs.

Keep generation and review separate

The strongest review pattern is organizational: never let the same conversation both write and grade the document. A model reviewing its own fresh output inherits the context and assumptions that produced the mistakes. Run critique as a separate request with a reviewer role in the system prompt — per the docs, even a one-sentence role ("you are a skeptical procurement reviewer; your job is finding gaps, not fixing them") measurably focuses behavior and tone. Instruct the reviewer to evaluate, not rewrite: "Do not produce a corrected version; list findings only." Otherwise Claude's helpfulness pulls it back into generation.

Rule of thumb: calibrate your reviewer the way you'd calibrate a new hire — give it 3–5 example reviews (Anthropic's recommended few-shot range, in <example> tags) including at least one that reaches a negative verdict. A reviewer that has never seen a "reject" example rarely issues one.

Finally, treat the reviewer itself as a system under test. Keep a small set of documents with known, human-agreed defects and check that prompt changes still catch them — the same empirical-evaluation discipline Anthropic's prompt-engineering overview recommends before any prompt tuning.

Where to go next

Review prompts pair naturally with self-critique patterns and confidence and hedging. For grounding findings in sources, see citations and sourcing; for building the test set, the evaluation framework.

Sources