What you need to know
Why examples work
Detailed instructions describe what you want; examples show it. When instructions produce inconsistent formats or judgement, few-shot examples are the most effective fix. They do three jobs:
- Fix the output format: every finding has location, issue, severity and suggested fix, in the same order.
- Show judgement on ambiguous cases: which tool to use for an unclear request; whether an uncovered branch matters.
- Help Claude generalise: from a few well-reasoned examples it handles new patterns, not only the ones listed.
How many, and which
Two to four targeted examples usually beat twenty. Spend them on the ambiguous cases, not the obvious ones, and include the reasoning: why this action was chosen over a plausible alternative.
<example>
Code: switch (s) { case A: start(); /* falls through */ case B: run(); }
Decision: skip
Reason: the comment marks the fall-through as intentional.
</example>
<example>
Code: switch (s) { case A: start(); case B: run(); }
Decision: report (medium)
Reason: no break and no comment; likely an accidental fall-through.
</example>Pairs like these, an acceptable pattern next to a genuine issue, cut false positives while still catching real bugs.
Few-shot for extraction
Examples also reduce hallucination and empty fields in extraction:
- Show correct extraction from varied structures: inline citations versus a bibliography; a methodology section versus details scattered in the text.
- Show informal values handled correctly ("about two metres" becomes
{"value": 2, "unit": "m", "approximate": true}). - Show date formats from several sources all normalised to one output format.
Examples anchor output
Examples are powerful in both directions. If all your examples are short Python functions, results on a 200-line Go file will lean towards short Python habits. Choose examples that match the kind of input the prompt will see, or vary them deliberately.
In the exam
Look for inconsistent formatting despite detailed instructions, intentional patterns flagged as bugs, wrong tool choice on ambiguous requests, empty required fields in extraction, or weak results on inputs unlike the examples.
Check your understanding
A reviewer keeps flagging intentional fall-throughs marked with comments. Detailed instructions have not helped. What should you add?
Show answer
Answer: C. Paired examples with reasons teach the distinction and generalise to similar patterns, without banning real findings.
How many few-shot examples should a review prompt usually include, and what should they show?
Show answer
Answer: A. A few targeted examples with reasoning give consistency and judgement on the hard cases at a small context cost.
Few-shot refactoring examples are all under ten lines, and results on a 200-line function are weak. What is the likely cause?
Show answer
Answer: D. Examples anchor the output to what they show. Examples far from the real input's scale or style generalise poorly.
Apply it: Bayview's date and amount examples
Bayview's dates come out in mixed formats and amounts like "approx. 1,200 EUR" are sometimes dropped. Write the few-shot block.
- Choose three examples that together cover the date formats in the case and one informal amount.
- Write each example with input text, output fields and a one-line reason.
- Add one example for a missing value, showing null rather than a guess.
- Say how you would check that the examples help and do not over-anchor.
Show model answer
1 and 2. Examples
| Input | Output | Reason |
|---|---|---|
| "Invoice date: 03/04/2026" (UK supplier) | "invoice_date": "2026-04-03" | UK suppliers write day first |
| "Issued 4 Mar 26" | "invoice_date": "2026-03-04" | Two-digit year means 20xx |
| "Total approx. 1,200 EUR" | "total": {"amount": 1200, "currency": "EUR", "approximate": true} | Keep informal amounts, flag them |
3. Missing value. Input with no tax ID anywhere: "vendor_tax_id": null, reason "No tax ID appears in the document; never construct one."
4. Check. Run 200 sampled documents with and without the examples and compare format consistency and null-versus-invented rates. Include receipts and contracts in the sample, so the invoice-heavy examples are tested on other types too.