Providing examples

Some things are easier to show than describe. "Classify tweets as positive or negative" is a fine instruction until you hit a sarcastic tweet, at which point you realise that "positive sentiment" is not the same as "positive words." You could write three paragraphs explaining sarcasm to Claude — or you could show it one sarcastic example and let the model figure out the pattern from the demonstration. The second is almost always better.

One-shot and multi-shot prompting

One-shot prompting means including a single example input/output pair in your prompt. Multi-shot means including several. Both techniques rely on Claude's strong pattern-matching: shown what a correct answer looks like for one input, the model generalises that shape to other inputs.

• One-shot — use when the task is simple and one demonstration is enough to nail down the pattern.
• Multi-shot — use when there are multiple valid shapes, when edge cases vary, or when you need to cover subtly different scenarios.

Examples are especially effective for:

• Corner cases and edge scenarios (sarcasm, ambiguous inputs, unusual formats)
• Complex output formats (specific JSON shapes, structured tables, nested data)
• Precise style and tone (matching an existing brand voice, house style, or formatting convention)
• Ambiguous inputs where the rule is hard to describe verbally but easy to show

The sarcasm problem

Sentiment classification is a classic case. A tweet like:

"Yeah, sure, that was the best movie I've seen since 'Plan 9 from Outer Space'."

reads positive on the surface. Every word is complimentary. But Plan 9 is famously one of the worst films ever made, so the whole thing is sarcastic — and the correct label is negative.

Without examples, Claude will sometimes catch the sarcasm and sometimes not. Describing sarcasm in prose ("be careful with sarcastic statements that use positive words ironically") helps but isn't reliable.

With examples:

Classify the following tweet as Positive or Negative.

<sample_input>
Great game tonight!
</sample_input>
<ideal_output>
Positive
</ideal_output>

<sample_input>
Oh yeah, I really needed a flight delay tonight! Excellent!
</sample_input>
<ideal_output>
Negative
</ideal_output>

Pay particular attention to sarcasm — positive-sounding statements
can express negative sentiment.

<sample_input>
{tweet}
</sample_input>
<ideal_output>

Now Claude has a direct demonstration: "when the words are positive but the meaning is clearly ironic, the label is Negative." The example does the explaining for you.

Wrap examples in XML tags

Always wrap examples in descriptive XML tags — <sample_input>, <ideal_output>, <example>, whatever fits your task. The tags serve the same purpose they did in the previous lesson: unambiguous boundaries between sections. When Claude can see "this block is an example, that block is the real input to classify," it treats them correctly. Without the boundaries, the examples can bleed into the real task.

Prefilling the final <ideal_output> tag — as in the sarcasm example above — uses the same prefill pattern you learned in Module 3. Claude continues the assistant turn from inside the tag and writes only the label, with no extra framing.

Explain why each example is ideal

A one-line addition that makes examples substantially more effective: tell Claude why the example output is good, not just that it is.

<ideal_output>
[Example meal plan here]
</ideal_output>

This example is well-structured, provides exact portions and timing,
and clearly aligns with the athlete's stated goals and dietary restrictions.

That commentary turns a demonstration into a demonstration with a rubric. Claude isn't just pattern-matching the shape — it's picking up the evaluative criteria you care about. For complex outputs this single sentence is often worth another half-point on the eval score.

Source examples from your highest-scoring runs

Where do you get good examples? The best place is the output of your previous eval runs. Look at the cases that scored a 9 or a 10 on the current prompt. Those are, by definition, outputs that the grader already thinks are excellent. Pull one into the prompt as an example, and you're explicitly showing Claude what your own grading process rewards.

This closes a useful loop:

1. Run the eval.
2. Identify the top-scoring output.
3. Pull it into the prompt as a one-shot example.
4. Rerun the eval — the average should climb as the whole dataset trends toward the shape of the example.

When the eval's own feedback drives example selection, your prompt and grader stay in sync.

Best practices, condensed

| Practice | Why | |---|---| | Always wrap examples in XML tags | Unambiguous boundaries between examples and the real task | | Be explicit ("Here is an example input with an ideal output") | Claude knows not to treat the example as the actual request | | Include examples that target your most common failure cases | Maximum leverage per example | | Explain why each example output is ideal | Conveys rubric, not just shape | | Source examples from highest-scoring eval outputs | Aligns prompt with grader | | Keep examples tightly relevant to the task | Off-topic examples confuse rather than help |

When to reach for examples

The rule of thumb:

• If a single clear instruction and a set of guidelines get you to the score you need, skip examples. They add prompt length and token cost.
• If the grader is complaining about format, tone, or edge-case handling after you've applied clarity, specificity, and XML structure, reach for examples. They're the right tool for "I want it to look like this specific thing."

Examples show rather than tell. That's their whole power. When a requirement is easier to demonstrate than describe, examples are the lowest-effort highest-value technique you have.