Few-shot examples

Instructions describe what you want. Examples show it. A handful of worked input-to-output pairs (few-shot or multishot prompting) is one of the most reliable ways to fix output format, tone and the judgement calls that are hard to put into words, such as “what counts as page-worthy”.

What good examples look like

The official guidance asks for examples that are:

• Relevant. They mirror your real inputs: actual alert text from your monitoring stack, not textbook sentences.
• Diverse. They cover the edge cases and vary enough that Claude doesn’t latch on to an accidental pattern (the same service name, the same length, the same label).
• Structured. Each one sits in <example> tags, and the set sits in <examples>, so Claude can tell examples apart from instructions and from the real input.

Three to five examples is the recommended starting point. More is not automatically better: every example costs input tokens on every call. If you use a long, stable set, put it in the cached part of the prompt.

A runnable classifier

import os
import sys

import anthropic

client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

SYSTEM = """You triage monitoring alerts for a platform team.
Classify each alert as page (wake someone now), ticket (fix in working hours) or ignore.
Paging costs someone their sleep, so page only for user impact or imminent data loss.
Answer in exactly this form: <label>LABEL</label> <why>one short sentence</why>

<examples>
<example>
<alert>5xx rate 18% on checkout-api for 6m (SLO burn 14x)</alert>
<label>page</label> <why>Users are failing to check out and the error budget is burning fast.</why>
</example>
<example>
<alert>Certificate for internal-grafana.example.net expires in 21 days</alert>
<label>ticket</label> <why>Real work, but there are weeks before any impact.</why>
</example>
<example>
<alert>CPU 92% on batch-worker-3 during the nightly report job</alert>
<label>ignore</label> <why>Expected load for a scheduled batch job with no user impact.</why>
</example>
<example>
<alert>etcd member 2 of 3 unreachable for 4m in prod-eu cluster</alert>
<label>page</label> <why>One more failure loses quorum and the control plane.</why>
</example>
</examples>"""

alert = " ".join(sys.argv[1:])
response = client.messages.create(
    model="claude-haiku-5-5",
    max_tokens=1024,
    system=SYSTEM,
    messages=[{"role": "user", "content": f"<alert>{alert}</alert>"}],
)
print("".join(b.text for b in response.content if b.type == "text"))

Notice what the examples do that the instruction alone can’t. They fix the exact output shape. They show that high CPU is not always bad. And the etcd case teaches a reasoning pattern (one failure away from losing quorum) that carries over to new alerts.

Pitfalls

• Examples that contradict the instructions. If the system prompt says “one sentence” and an example has three, the example usually wins. Keep them consistent.
• Examples mixed into the data. Without tags, Claude may treat an example alert as one more input to classify. Keep them inside <examples>, apart from the real input.
• Only easy cases. The value is in the borderline ones. Add the cases your team actually argues about, with the decision you want.

You can also ask Claude to review your example set for relevance and diversity, or to draft more examples from your first few, then edit them by hand.

Examples with thinking and tools

Few-shot still works when thinking is on: worked examples shape how Claude approaches similar problems in its thinking. Present each as the problem, the method, and the expected answer.

For tools there is a dedicated field. A tool definition can include input_examples, a list of sample inputs that must each validate against the tool’s input_schema (otherwise the request returns a 400 error). Use it for tools with nested or format-sensitive parameters, and keep the description as the main source of guidance.

Recap

• Few-shot examples pin down format, tone and judgement better than instructions alone.
• Use three to five relevant, diverse examples, each in <example> inside <examples>.
• Balance labels and vary surface details, or Claude will copy the accidental pattern.
• Keep examples consistent with the instructions and separate from the real input.
• Tools take schema-valid samples in input_examples.