Show Claude examples with few-shot prompting

Few-shot prompting means putting a small number of worked examples (input and the exact output you want) directly in your prompt. Claude reads the pattern and matches it. Two or three good examples steer format, tone, and structure more reliably than a paragraph of instructions describing the same thing.

The one-line idea

Telling Claude "return the result as a bullet list, present tense, no preamble" works. Showing Claude one filled-in example of that bullet list works better, because the example removes every ambiguity at once. You do not have to name the rules. The example carries them.

This technique has names. "Zero-shot" is a prompt with no examples. "One-shot" has a single example. "Few-shot" (also called multishotAnother name for few-shot prompting: providing several example input/output pairs in the prompt to steer the model) has several. The more an output has a precise shape you care about, the more examples earn their place.

When should I use examples instead of instructions?

Reach for examples when the output has a shape that is hard to describe but easy to show.

Reach for plain instructions instead when the task is open-ended ("explain this code"), when the format is already obvious, or when you only need it once and do not care about exact shape.

A first example

Say you want short release-note lines from commit messages. Describing the format in prose leaves gaps: How long? Past or present tense? Does it keep the ticket number? Show it instead.

The two examples settle every open question: past tense, full sentence, no ticket number, no commit-type prefix. Claude follows the shape on the third input without being told the rules in words.

How many examples should I use?

Anthropic's prompt-engineering guidance recommends three to five examples for the best results. One example fixes the basic shape. A second confirms the pattern is intentional, not an accident of the first. A third through fifth let you cover variety. Past that, returns drop and you are paying tokens for little gain.

Each example costs tokens on every turn it stays in context. That is a fair trade when the examples buy you a reliable format, and it is the reason you stop adding them once the pattern holds. For how that token cost works, see token usage and cost.

What makes a good few-shot example?

Three properties separate examples that steer well from examples that mislead.

Relevant

Mirror the real task. If you classify support tickets, your examples are real-looking support tickets, not toy sentences. Claude generalises from the surface details it sees, so off-topic examples drag the output off-topic.

Diverse

Vary the examples so Claude learns the rule, not an accidental quirk. If all three of your examples happen to be one-word answers, Claude may decide one word is the rule. Cover the range you expect in production, including at least one edge case. Diverse examples also stop Claude from latching onto an unintended pattern, like always starting with the same verb.Common gotchaWatch for content bleed: if every example happens to mention "Acme" or returns three bullets, Claude often copies that literal value into a new answer where it does not belong, because it cannot tell the format from the contents.Vary the concrete details (names, counts, lengths) across your examples so the only thing they share is the shape you want.

Structured

Wrap each example in tags so Claude can tell examples apart from instructions and from the live input. Anthropic's guidance is to wrap each example in <example> tags, and a set of them in <examples> tags.

The tags do real work. Without them, a long example can blur into the instructions and Claude may treat your sample input as the task to answer.Common gotchaFor classification, balance the labels: a set of four "billing" examples and one "technical" quietly biases Claude towards the label it saw most.Give each label a roughly equal count, and shuffle the order so the last example is not always the same class.

Show the reasoning, not just the answer

For tasks that need a judgement call, show the thinking inside the example, not only the final answer. Put the reasoning in a <thinking> tag and the result in an <answer> tag. Claude generalises the reasoning style, so the pattern you demonstrate shapes how it reasons on new inputs. This pairs well with asking Claude to think before it answers.

Showing the reasoning is more useful than showing the verdict alone, because the next input will be different and Claude needs the method, not the memorised answer.

Where should I put my few-shot examples?

The strongest place for examples is not a one-off chat message. It is a file Claude reads on every turn, so you write the examples once and they steer every session.

In the Claude Code CLI, that file is the project memory file at the repo root. Put a short, clearly-labelled set of examples under a heading, and they persist without re-pasting.

## Commit message format
 
Write commit messages in this exact shape.
 
<example>
fix: stop the cart total from going negative on coupon stacking
</example>
 
<example>
feat: add keyboard shortcuts to the search bar
</example>

Claude Code loads this file at the start of every session, so the examples shape its output the same way each time. For the mechanics of memory files and where they load from, see rules and memory files. For why a stable, cached file is cheaper than re-pasting examples each turn, see prompt caching.

You can also keep examples in a separate document and point Claude at it when the task comes up:

Ask Claude to build the examples

You do not have to write every example by hand. Claude can draft a set from a single seed, then you correct the ones that are wrong. The corrected set becomes your few-shot block.

You can also have Claude grade your existing examples for the two properties that matter most.

This is a fast way to find the gap you did not notice, such as five examples that all happen to be short.

Common mistakes

A few failure modes show up again and again.

The contradiction case is worth naming twice. When your prose says one thing and your example shows another, the example usually wins. So the example is not decoration. It is the spec, and it has to be right.

A workflow that compounds

Few-shot prompting pays off most when you treat the examples as an asset you keep.

Start with one example in a chat. When the format is right, promote the best examples into a file Claude reads every time. Now the format is a property of the project, not something you re-explain on each task.

When should I not use few-shot prompting?

Examples are not free and they are not always the answer.

• You need a guaranteed machine-readable shape. If the output must be valid JSON that conforms to a schema every time, a few examples help but a stricter mechanism is better. See structured outputs.
• The task is open-ended. "Review this PR and tell me what worries you" has no fixed shape to demonstrate. Plain instructions fit better.
• The examples would be huge. If one example is a 500-line file, three of them dominate the context. Trim to the smallest example that still shows the pattern.

Checklist

Before you ship a few-shot prompt, confirm:

• Each example mirrors the real task, not a toy version of it.
• You have three to five examples for an important format, and they vary.
• Every example is wrapped in <example> tags, and the set in <examples> tags.
• All examples follow the exact same shape, so the pattern is unmistakable.
• No example contradicts the instructions.
• For a stable format, the examples live in the project memory file, not a single message.

Get those right and Claude matches your format on the first try, on the tenth try, and across everyone on the team using the same file.