- In short
- Example based communication is the refinement move of replacing prose descriptions with two or three concrete input/output examples when Claude interprets an instruction inconsistently. Instead of describing the transformation in words, you demonstrate it, because the model generalises a pattern from a small set of consistent examples more reliably than it follows a longer description.
What example based communication means
Example based communication is the practice of teaching Claude what you want by showing it, with concrete input/output pairs, rather than telling it in prose. When an instruction is being interpreted inconsistently, the output is structurally right sometimes and wrong other times despite a careful description, example based communication is the refinement that closes the gap. It is the applied, hands-on form of the principle that sits at the top of the refinement hierarchy: demonstrations move output more reliably than descriptions.
The technique is deceptively simple to state and easy to get wrong in practice. You take the transformation you have been describing in words and you replace, or augment, that description with two or three worked examples of it actually happening. Each example pairs an input with the exact output you would want for that input. The model reads the pairs, infers the rule that connects them, and applies that rule to inputs it has never seen. This knowledge point is tested at the apply level precisely because recognising the idea is not enough; the exam wants you to convert a failing prose prompt into a working example-based one.
- Example based communication
- Refining a prompt by replacing prose description with concrete input/output examples. Used when Claude reads an instruction inconsistently, it shows two or three demonstrations of the expected transformation so the model generalises the pattern. Examples must be mutually consistent, because contradictory examples actively teach the wrong behaviour.
The symptom that triggers the switch
The discipline is not "always use examples"; it is "switch to examples when you see a particular symptom." That symptom is inconsistency under a clear instruction. You have written what feels like an unambiguous description, yet the output varies: the JSON fields come back in a different order, the summary is sometimes three sentences and sometimes a paragraph, the generated component is named one way here and another way there. The instruction is not vague to you, but it is evidently being read loosely by the model. That gap between your clarity and the model's variance is the signal.
When you see it, resist the pull to rewrite the description more forcefully. A more detailed paragraph is the weakest rung of the hierarchy and rarely fixes inconsistency, because the problem was never a missing rule. It was a rule expressed in a form the model interprets loosely. Examples express the same rule in a form the model interprets tightly. Anthropic's prompting guidance is blunt about the leverage here: well-chosen examples are among the most effective ways to lift output quality and consistency, especially for tasks with formatting or structural requirements.
Why generalisation makes examples reliable
The reason examples outperform prose is generalisation. A prose instruction is a compression of the result into language, and the model must decompress it back into a concrete output, filling every gap your words left with its own guess. Different guesses on different runs produce the inconsistency you are seeing. A set of examples removes most of the guessing: the model has actual instances of the target, and it extracts the shared structure across them directly. The conventions that are genuinely hard to articulate, spacing, ordering, the precise shape of an edge case, are simply present in the demonstrations.
This is also why the consistency of your examples matters so much. The model generalises whatever pattern your examples share, so if two examples disagree, one puts the id first, another puts it last, you have taught it that either is acceptable, and you will get both. Contradictory examples do not merely fail to help; they actively encode the wrong lesson. A small set of mutually consistent examples is therefore worth far more than a large, sloppy one, and getting two examples to agree precisely is most of the work of applying this technique well.
Applying it well in Claude Code
In day-to-day Claude Code work, example based communication usually means putting the demonstrations where they will be read. For a one-off task, you paste the examples into the prompt itself. For a convention the whole team relies on, a commit-message style, a test layout, a naming scheme, the examples belong in the project configuration so every session inherits them, which is where this technique meets the configuration hierarchy. Either way, the move is the same: find the transformation that is being read inconsistently and replace the description of it with instances of it.
There is a judgement call about what to demonstrate. Good examples are representative and cover the variation that matters: include an edge case if edge cases are where the drift appears, and keep the set small enough to stay consistent. Few-shot prompting at the API level is the same idea formalised, and the deeper treatment of why a handful of examples is the highest-leverage prompting move lives in few-shot as the highest-leverage technique. The Claude Code framing of this knowledge point is just that idea applied to an iterative coding loop: when telling has failed, show.
Worked example
A team asks Claude Code to generate TypeScript React components and writes a careful CLAUDE.md rule: 'name components in PascalCase, colocate styles, export a typed props interface above the component'. The generated components keep varying, sometimes the interface is below the component, sometimes props are inlined, sometimes the file name does not match.
The instruction is clear to a human, yet it is being read inconsistently, which is the exact trigger for switching to examples. Adding more rules to the prose would be climbing down to the weakest rung; instead the team demonstrates the target.
They add two complete, consistent examples to the configuration. Each shows a small input, "a Button that takes a label and an onClick", paired with the full file Claude should produce: the ButtonProps interface declared above the component, the Button function in PascalCase, the colocated Button.module.css import, and the file named Button.tsx. The second example does the same for an Avatar with an optional size prop, so the optional-field convention is also demonstrated rather than described.
From then on, new components match. The model generalised the shared structure across the two demonstrations, interface above, PascalCase name, colocated styles, matching file name, and applied it to components it had never seen. Crucially, the two examples agreed with each other in every detail; had the second placed the interface below the component, the team would have re-introduced the very inconsistency they were trying to remove. The fix was not a better paragraph. It was two examples that say the same thing.
Encoding examples as message turns
Beneath the day-to-day practice sits a structural reality worth understanding: Claude's Messages API is stateless. The model retains no memory of earlier turns between requests, so every example you want it to learn from must be present in the messages array you send on each call. When you show Claude examples, you are really assembling a conversation, a sequence of user and assistant messages, and resending the relevant parts of it every time. Nothing persists on the server for you; the context you supply on this request is the entire context the model sees.
That has a consequence the documentation makes explicit: the earlier turns do not have to be things Claude genuinely said. You can hand it synthetic assistant messages, demonstrations you wrote yourself, paired with the user inputs that should produce them, and the model treats them as worked examples of the behaviour you want. This is exactly how few-shot examples are delivered at the API level: a handful of input/output pairs encoded as alternating message turns, ending with the real input you want answered. The content of each message can be a plain string or an array of content blocks, so a multimodal demonstration fits the same shape as a text one.
One placement rule trips people up. A global instruction that should govern the whole exchange belongs in the top-level system field, not as the first entry of messages. The system field is the right home for the standing rule, emit JSON in this schema, while the messages array carries the demonstrations of that rule in action. Keeping the instruction in system and the examples in the conversation is the cleanest way to combine telling and showing without the two competing for the same slot.
What makes an example worth showing
Switching to examples is only half the skill; the other half is choosing examples that teach the right thing. Anthropic's prompting guidance names three properties to aim for. Examples should be relevant, they should mirror your actual use case rather than a toy version of it. They should be diverse, varied enough to cover the edge cases and corners where output tends to drift, so the model does not over-fit to an accidental feature of a single sample. And they should be structured, wrapped in <example> tags, or <examples> for a set, so the model can tell a demonstration apart from an instruction. The same guidance puts a number on it: include three to five examples for the best results on a non-trivial task.
Notice how diversity and consistency cooperate rather than conflict. The rule the examples encode must stay consistent, every example places the interface above the component, every example uses the imperative mood, while the inputs should vary, so that the consistent rule is demonstrated across genuinely different cases. This matters even more with current models, which interpret a prompt literally and do not silently generalise an instruction from one shape to another; a demonstration of each shape you care about removes the guesswork that a single description leaves behind. Two further levers are worth knowing: positive examples that show the desired behaviour steer the model more reliably than negative ones that merely describe what to avoid, and you can ask Claude itself to evaluate your examples for relevance and diversity, or to draft additional ones from an initial pair.
Common misreadings to avoid
Misconception
Good examples should be as similar to each other as possible, so the model sees one clean, unambiguous pattern.
What's actually true
Misconception
When examples are not enough, the next step is to add more and more examples until the behaviour is pinned down.
What's actually true
Misconception
Examples are a training-time technique; to change behaviour at prompt time you must describe what you want more precisely.
What's actually true
Where this sits in the refinement strand
Example based communication is the apply-level expansion of the top rung of the technique hierarchy for refinement, and it is one of the two techniques whose feedback you must decide how to package in batch versus sequential feedback. It also pairs with test-driven iteration with failing tests: examples are the right move for inconsistent format, while tests are the right move for ambiguous behaviour. Knowing which symptom calls for which technique is the evaluate-level skill covered in when to switch refinement techniques.
How it shows up on the exam
This knowledge point is tested at the apply level, mostly within Scenario 2 (code generation with Claude Code) and Scenario 5 (Claude Code for continuous integration). A question describes a developer whose careful, detailed instruction still yields inconsistent output and who is about to add yet more prose, then asks for the better move. The answer is to switch to concrete examples: show two or three consistent input/output pairs of the transformation. Watch for the distractor that recommends more detailed instructions, it is the trap this knowledge point exists to defeat, and for any option that suggests piling on inconsistent examples, which would teach the wrong pattern. Match the symptom of inconsistent format to the remedy of consistent examples and the question resolves cleanly.
A developer asks Claude Code to convert raw log lines into a fixed structured format. Their prompt describes the target format in three detailed sentences, but the output structure keeps varying between runs. They want the most reliable single change to make the format consistent. Which should they do?
People also ask
When should I switch from instructions to examples with Claude?
How many examples should I give Claude?
Why do examples work better than detailed instructions?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Prompting 101 | Code w/ Claude
Why watch: Shows live how swapping vague prose for 2-3 concrete examples makes Claude's output consistent, exactly the move this KP prescribes when instructions are interpreted inconsistently.
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.