Multishot: Teaching by Example

Why examples beat instructions

Multishot prompting (also called few-shot prompting) means including worked examples of the input-output behavior you want, right in the prompt. It is one of the most reliable ways to steer Claude's format, tone, and structure — often more reliable than any amount of prose description.

The reason is simple: examples are unambiguous. A rule like "keep summaries concise and professional" leaves "concise" and "professional" open to interpretation. An example summary shows the exact length, tone, and structure you mean. Examples are the pictures worth a thousand words for a language model: 3-5 curated, diverse examples routinely beat an exhaustive list of edge-case rules stuffed into instructions.

The three qualities of good examples

Relevant. Examples should mirror your actual use case — same kind of input, same kind of output. If you're classifying support tickets, use real (anonymized) tickets, not invented toy sentences.

Diverse. Your examples should cover the range of inputs you expect, including edge cases. This is the quality people get wrong most often, and it matters because Claude learns every pattern your examples share — including patterns you didn't intend.

Structured. Wrap examples in <example> tags (inside an <examples> wrapper when there are several) so Claude can cleanly tell examples apart from instructions and from the real input.

The accidental-pattern trap

Suppose you're building a ticket router and your three examples are:

• "App crashes when I upload a photo" → technical
• "App freezes on the settings page" → technical
• "App shows a black screen on launch" → technical

You intended to teach the categories. You also taught that everything is technical, that every ticket starts with "App", and that tickets are one sentence long. When a two-paragraph refund request arrives, the model is off the map you drew.

The fix is diversity across every dimension that varies in real data: category, length, phrasing, and difficulty. Include at least one ambiguous case with the judgment call you want:

<examples>
<example>
Ticket: My card was charged twice for the March invoice.
Category: billing
</example>
<example>
Ticket: The app crashes every time I upload a photo from my camera roll.
Category: technical
</example>
<example>
Ticket: How do I add a second user to my account?
Category: how-to
</example>
<example>
Ticket: I was charged after canceling, and now the app won't open at all.
Category: billing
Note: when a ticket spans categories, choose the one requiring account access.
</example>
</examples>

A router built this way — four diverse labeled examples — outperforms a long prose rule list describing each category.

Let Claude audit your examples

You don't have to eyeball diversity yourself. Two useful moves:

• Paste your examples and ask: "Evaluate these examples for relevance and diversity. What unintended patterns do they share? What real-world cases do they miss?"
• Ask Claude to generate more examples from your initial set, then hand-correct them. Correcting is faster than authoring, and your corrections sharpen exactly the boundaries the model was unsure about.

Teaching reasoning, not just answers

Examples can carry reasoning style too. If you put <thinking> tags inside your few-shot examples — showing the reasoning that leads to each answer — Claude learns the reasoning pattern, not just the input-output mapping. This is useful when the judgment matters as much as the label: grading rubrics, triage decisions, code review severity calls.

<example>
Ticket: I was charged after canceling my subscription.
<thinking>
Mentions a charge, so billing is a candidate. Cancelation implies an
account-state check, which support can't do without billing access.
</thinking>
Category: billing
</example>

When to reach for multishot

Use examples when format or tone matters and prose keeps failing to pin it down, when the task involves judgment calls with fuzzy boundaries, or when outputs must be highly consistent across many runs. Skip them when the task is trivial ("translate this to French") — examples add tokens and, done carelessly, add wrong patterns.

On count: 3-5 well-crafted examples is the sweet spot for most tasks. One example anchors too hard on its specifics; a dozen adds tokens faster than it adds signal. If five diverse examples still aren't pinning the behavior down, the problem is usually the task definition, not the example count — go back and sharpen the instructions.

And remember the order of operations: examples refine a clear prompt, they don't rescue a vague one. State the task clearly first; then let 3-5 good examples do the fine-tuning that instructions can't.