- In short
- Constructing few-shot examples means writing a small set of two to four worked demonstrations inside the prompt, each pairing an input with the chosen output and the reasoning for why that output was correct. The reasoning is what lets Claude infer the underlying decision rule and apply it to inputs it has never seen, rather than copying surface patterns.
What constructing few shot prompting examples means
Constructing few shot prompting examples is the practical skill of writing a handful of worked demonstrations, usually two to four, and placing them inside your prompt so Claude can apply the same pattern to new inputs. It is the highest-leverage move you have once you have decided that examples are the right fix, and it is squarely an apply-level skill: the exam expects you to build the examples, not merely recognise that examples help.
The temptation is to treat an example as a labelled pair, an input on one side and the correct answer on the other. That produces a demonstration of what to output, but not of why. The craft covered by this knowledge point is making each example carry its own justification, so the set as a whole teaches a transferable decision rule rather than a lookup table.
- Effective few-shot example
- A worked demonstration inside the prompt that shows an input, the chosen output, and the reasoning for why that output beats a plausible alternative, so the model infers the decision rule and generalises to unseen inputs.
Why two to four targeted examples beat a longer generic list
More is not better with examples. A handful of examples that each illustrate a genuinely tricky decision will move output quality far more than a dozen that all rehearse the obvious case. The goal is coverage of the hard part of your decision space, not volume. If your task is mostly straightforward but goes wrong on a narrow band of confusing inputs, every example you spend on an easy case is a wasted slot.
Anthropic's own documentation lands in the same place from the opposite direction, recommending three to five examples that are relevant (mirroring your real inputs), diverse (covering edge cases so the model does not latch onto an accidental regularity), and clearly structured so Claude can tell the demonstrations apart from your instructions. The number is a guideline, not a quota. Two razor-sharp examples can outperform five loose ones, which is why this skill is about selection and construction rather than counting.
There is a second, subtler reason to keep the set small. Every example you add is also a chance to introduce an unintended pattern, a shared phrasing or ordering that Claude may copy without you meaning it to. A tight, deliberately varied set minimises that risk while still anchoring the behaviour you want.
The anatomy of an example that generalises
Picture the strongest possible single example. It opens with a realistic input drawn from the messy middle of your task, not a clean textbook case. It states the output you actually want for that input. Then, critically, it explains the choice: this input looked like it might warrant action B, but the right move was action A because of a specific feature of the input. That final clause is the engine of generalisation.
When the reasoning is present, Claude is not just memorising the mapping from this input to this output. It is reading the criterion you applied and reusing that criterion elsewhere. Strip the reasoning out and you are back to pattern matching, where the model copies the form of your examples but stumbles the moment an input does not resemble one it has seen.
Why the reasoning is the whole point
Consider the difference between these two example styles for a code-review prompt. The first says: input is a function that swallows an exception, output is "flag this." The second says the same, then adds that it is flagged because the swallowed exception hides a failure the caller needs to handle, whereas a deliberately ignored, logged exception would not be flagged. The first teaches Claude to flag empty catch blocks. The second teaches Claude the actual rule about when silent failure is and is not a defect, which transfers to constructs the example never mentioned.
This is why the exam treats reasoning-bearing examples as the correct construction and bare pairs as the trap. A model given only outputs can reproduce them impressively on inputs close to the demonstrations and then fail unpredictably just outside that radius. The reasoning is cheap to write and it is precisely what buys you robustness on the novel inputs your production traffic will actually contain.
Choosing, ordering, and structuring your set
Selection comes first. Look at where your current prompt produces inconsistent judgements, then pick examples that sit on exactly those fault lines. Diversity matters more than similarity: two examples that disagree in instructive ways (one that warrants action, one that deliberately does not) teach the boundary far better than two that both say yes.
Structure comes next. Wrap each demonstration so Claude can distinguish it from your instructions, which is why Anthropic suggests enclosing examples in clear tags. Keep the formatting of the example output identical to the format you want in production, because Claude is attentive to detail and will replicate naming, casing, and layout it sees in your examples.
How this knowledge point is tested
Domain 4 carries 20% of the Claude Certified Architect exam, and this task statement, applying few-shot prompting to improve output consistency, is one of its most practical threads. Questions in scenarios 5 (continuous integration) and 6 (structured data extraction) tend to describe a prompt that already has detailed instructions yet still produces inconsistent judgements, then ask what to add. The correct answer is rarely "more instructions" and rarely "a confidence threshold." It is a small set of examples, and the best-scoring choice is usually the one that specifies the examples should include the reasoning behind each decision.
A common distractor offers examples without reasoning. On the surface it looks right because it does reach for examples. It is wrong because, as this knowledge point stresses, bare examples enable pattern matching but not the generalisation the scenario needs. Before you build, it helps to confirm few-shot is even the right tool, which is the job of recognising when to deploy few-shot examples; and it builds on the foundational idea that few-shot is the highest-leverage technique for consistency.
Worked example
A CI code-review agent inconsistently flags comments that disagree with the code. You decide to add few-shot examples to make its judgement consistent.
Your instructions already say to flag comments whose claimed behaviour contradicts the actual code. Yet the agent flags some harmless stale comments and misses some genuinely misleading ones. Rather than adding another paragraph of rules, you construct three examples.
Example one: a comment says "returns the cached value" above a function that recomputes every call. Chosen output: flag it. Reasoning: the comment asserts a behaviour (caching) that the code contradicts, which can mislead a caller into assuming cheap repeated calls.
Example two: a comment says "TODO: optimise later" above a slow but correct loop. Chosen output: do not flag. Reasoning: the comment makes no false claim about current behaviour; it is a note about future work, and flagging it would be a style or backlog preference, not a contradiction.
Example three: a comment says "input is already validated" above code that re-validates. Chosen output: do not flag. Reasoning: the comment is slightly redundant but not contradictory, and the defensive re-validation is a deliberate local pattern.
Notice what these three teach together. They do not just label outputs; they draw the line between "the comment lies about behaviour" (flag) and "the comment is merely outdated, aspirational, or redundant" (skip). With that rule made explicit through reasoning, the agent now handles a fourth, never-demonstrated case, a comment claiming a function is thread-safe when it mutates shared state, correctly, because it has learned the criterion rather than the surface form of the examples.
Why examples carry knowledge instructions cannot
There is a deeper reason the exam keeps steering you toward examples over extra instructions, and it is worth making explicit. Much of what you want Claude to do is tacit: it lives in the gap between what you can articulate and what you actually mean. You recognise a flagged contradiction when you see one, but the complete rule resists being written down without becoming a sprawling, brittle policy document. A worked example sidesteps that by demonstrating the judgement in situ, letting the model infer the unwritten parts from a concrete case.
This is also why piling on instructions so often backfires. Each new rule you add interacts with the others, spawns exceptions, and invites the model to lawyer the edges of your wording. A handful of examples compresses the same guidance into demonstrations that are far less ambiguous than prose, because they show the resolved judgement rather than describing a procedure for reaching it. When you find yourself drafting a fifth clarifying sentence, that is the signal to convert the intent into an example instead.
That said, examples and instructions are partners, not rivals. Instructions set the frame and the non-negotiables; examples calibrate the judgement within that frame. The strongest prompts state the rule plainly once, then show two to four demonstrations that pin down how it applies to the cases the words alone leave fuzzy.
Where this sits in the wider prompt-engineering domain
Constructing examples never happens in isolation. It is one move within a Domain 4 toolkit that also includes explicit categorical criteria, structured output through tool use, and validation loops. Examples are the instrument you reach for when the output is well-formed but the judgement wanders, and they work best layered on top of clear criteria rather than as a replacement for them. A prompt that first states a crisp rule and then demonstrates it on a few hard cases gives Claude both the frame and the calibration, which is consistently stronger than either alone. Keeping that larger picture in mind stops you treating example construction as a silver bullet and helps you recognise, on the exam, when a described failure actually belongs to a sibling technique rather than to few-shot at all.
Misconceptions that cost marks
Misconception
The more few-shot examples I include, the better the model will perform, so I should add as many as I can.
What's actually true
Misconception
An example just needs to show the right input and the right output; the model will figure out the rest.
What's actually true
Putting it into practice
The discipline is small but exact: pick examples that sit on your real fault lines, write the chosen output in the exact production format, and always state the why. Do that with two to four cases and you give Claude a compact, transferable rule. Once your examples are solid for ordinary inputs, the natural next steps are tuning them for varied document structures in extraction and aiming them at genuinely ambiguous edge cases.
A continuous-integration review agent has detailed written instructions but still makes inconsistent judgement calls on borderline comments. An architect proposes adding few-shot examples. Which construction will best improve consistency on novel inputs the team has not seen before?
People also ask
How many few-shot examples should you use?
Should few-shot examples include reasoning?
Do few-shot examples teach generalisation or pattern matching?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Providing examples
Why watch: Constructing a small set of targeted examples is the practical skill of building effective few-shot prompts.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.