Few-Shot Prompting for Consistent Output Format

1.When instructions alone stop working

Say you have written careful instructions for a code reviewer or an extraction pipeline, and the output still drifts. One run lists findings as bullets, the next writes paragraphs, and a third leaves out severity. Adding more adjectives to the instructions rarely fixes this. Anthropic's prompting guide says it plainly: examples are one of the most reliable ways to steer Claude's output format, tone and structure. A few well-crafted ones improve both accuracy and consistency. The technique is called few-shot or multishot prompting.

Anthropic's prompt-engineering blog lists four reasons to reach for examples. The format may be easier to show than to describe. You may need a specific tone or style. The task may involve subtle patterns or conventions. Or simple instructions haven't produced consistent results. Exam scenarios usually describe that last case: the team has already written detailed instructions and the output is still inconsistent. The cookbook on generating test cases goes further. It calls giving Claude examples 'perhaps the best way to improve its performance', and says realistic inputs are half the work of building ideal input/output pairs.

Examples don't replace instructions. The same guide still tells you to be specific about the output format and constraints, and to explain why a constraint matters. Examples add the one thing prose struggles to pin down: what a finished answer actually looks like.

Sources123

2.Relevant, diverse, structured, and few

The prompting guide gives three properties that a useful example set needs. Each one prevents a particular failure.

Diversity does not mean volume. Anthropic's post on context engineering warns about a common habit: teams stuff a laundry list of edge cases into a prompt, trying to spell out every possible rule. Its advice is to curate a set of diverse, canonical examples that show the expected behaviour. In its words, examples are the 'pictures' worth a thousand words. The prompt-engineering blog's tip points the same way: start with one example, and add more only if the output still doesn't match what you need. For examples inside tool definitions, Anthropic's advanced tool use post suggests one to five per tool, built from realistic data rather than placeholders like "string" or "value".

Sources142

3.Showing the exact shape of each output

Anthropic's page on output consistency lists 'constraining with examples' as one of its main techniques. Its market-intelligence example shows how this works. The prompt gives Claude a single filled-in template for a made-up company, says 'Output following this example format', and then asks for two real competitors. Both answers come back with the same tags, the same SWOT breakdown and the same short strategy line.

<competitor>
  <name>Rival Inc</name>
  <overview>A 50-word summary.</overview>
  <swot>
    <strengths>- Bullet points</strengths>
    <weaknesses>- Bullet points</weaknesses>
    <opportunities>- Bullet points</opportunities>
    <threats>- Bullet points</threats>
  </swot>
  <strategy>A 30-word strategic response.</strategy>
</competitor>

The template also sets lengths ('A 50-word summary', 'A 30-word strategic response'). That is detail a format description often leaves out. You can apply the same move to a code reviewer that reports findings inconsistently. Write two or three example findings, each with the same fields: location, issue, severity and suggested fix. The sources don't show this particular schema, but the mechanism is the one the guide demonstrates. Claude reproduces the fields, their order and their level of detail because it has seen a finished answer.

The summarization cookbook shows how strongly Claude picks up format. The authors added three example summaries to a prompt without saying anything about format, and the new summary came back in the examples' sectioned layout. In their words, they didn't explicitly tell Claude to follow the format of the examples, but it seems to have picked up on it anyway.

Sources56

4.Generalising beyond the examples shown

Examples are not a lookup table. Claude works out the pattern behind them and applies it to inputs none of them covered. The prompting guide says the same about explanations: Claude is smart enough to generalise from the reason behind a rule. Examples give it something concrete to generalise from.

Anthropic's advanced tool use post shows how much an example set can teach without stating any rules. It gives three sample calls to a create_ticket tool: a critical bug, a feature request, and a title-only internal task. From these, Claude learns the date and ID formats. It also learns correlations that no schema states: critical bugs have full contact info and escalation with tight SLAs, while internal tasks have a title only. In Anthropic's internal testing, these examples raised accuracy from 72% to 90% on complex parameter handling.

The same ability can work against you, which is why the guide asks for diversity. If every example shares an incidental feature, such as the same length or the same kind of input, Claude may treat that feature as part of the pattern. Vary whatever shouldn't matter, so that only the intended judgement stays constant.

Sources167

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.The most reliable prompt lists every edge case and rule you can think of.Why is that wrong?

   Anthropic advises against laundry lists of edge cases. It recommends a small, curated set of diverse, canonical examples that show the expected behaviour.

   Covered in Relevant, diverse, structured, and few

2. 2.Few-shot examples only help with inputs that closely match one of the examples.Why is that wrong?

   Claude infers the pattern behind the examples and applies it to new inputs. That is why a few diverse examples are enough.

   Covered in Generalising beyond the examples shown