Examples in prompts
Show the model what good looks like (few-shot prompting).
Create a free account Try part of it here
Why it matters
Some things are easier to show than to describe. Think of a house style, a fiddly output format, or the line where one category ends and the next begins. You can put a few examples in the prompt to show the model what you mean. This is called few-shot prompting. It's the quickest way to get a model to match what you have in mind. It's the same move as handing a new team member three past emails and saying "like these."
What you'll be able to do
- Explain what examples teach a model, and when they help more than instructions alone
- Choose a small, varied set of examples that covers every label and the tricky cases
- Format examples in tags so the model can't confuse them with the real input
- Build a few-shot prompt from a list of labeled examples in code
What it covers
- Show, don't only tell
- What examples teach, intended or not
- Formatting examples
- Building the prompt in code
- Worked example: examples for a house style
Show, don't only tell
Picture your first day at a new job. Your manager could hand you a page of rules for answering customers. Or they could show you three good replies and say "like these." Most people learn faster from the replies. Models do too.
A prompt with instructions and no examples is called zero-shot. Add one worked example and it's one-shot. Add several and it's few-shot. ("Shot" here means example.)
Here's a concrete case. Say you sort support emails into four queues: billing, shipping, product and other. A queue is a to-do pile for one team. Instructions alone leave the edges fuzzy. Is "Where's my refund?" billing or shipping? Is "The jacket arrived with a torn seam" product or shipping? You could write a paragraph of rules. Or you could show the model a few cases you've already decided:
<examples> <example> <email>I was charged twice for order 5521.</email> <category>billing</category> </example> <example> <email>My refund still hasn't shown up after two weeks.</email> <category>billing</category> </example> <example> <email>The jacket arrived with a torn seam.</email> <category>product</category> </example> <example> <email>Tracking says delivered but there's nothing on my porch.</email> <category>shipping</category> </example> </examples>
Each example pairs an email with its right answer. The tags, like <email> and </email>, mark where each part starts and ends.
Two of those examples settle the unclear cases. Refunds are billing. Damage that arrives in the box is a product problem. That's the best use of an example: it decides a case your instructions left open.
Show the answer
billing
The second example shows a late refund labeled billing. That example settles the case, even though the word "late" sounds like shipping.
What examples teach, intended or not
A model treats your examples as strong evidence of what you want. It copies more than the labels. Think of a new hire who copies the sample emails a bit too well. They even pick up the sign-off you only used out of habit.
- Format: if every example answer is a single lowercase word, the replies will be too.
- Length and tone: three short, casual example emails pull the output toward short and casual.
- Accidental patterns: if every example happens to open with "Hi there," so will the output. If most of your examples are billing, the model leans toward billing.
- Mistakes: a mislabeled example teaches the wrong rule. It teaches it as faithfully as a correct example teaches the right one.
So choose your examples on purpose:
- Cover every label at least once.
- Vary them. Use different lengths, wording and situations. Then the model learns the rule, not surface details.
- Include the hard cases that sit near the line between two labels. Easy, repetitive examples cost tokens and teach little. (Tokens are the small chunks of text a model reads. You pay for each one.)
- Start with three to five. Add more when one kind of input keeps going wrong.
shipping. What's the most likely effect?Show the answer
The model leans toward shipping for new emails, and handles long or angry emails less reliably
Examples are strong evidence. A one-sided set tilts the labels toward shipping. A set with no long or angry emails gives no guidance for those.
Formatting examples
Think of a sample form stamped "SAMPLE." It looks exactly like the real form, so you can see how to fill yours in. The stamp stops anyone from mixing the two up. Examples in a prompt work the same way. Keep them clearly apart from the real input, and make them look exactly like it:
- Wrap each example in
<example>tags and the whole set in<examples>. - Use the same structure in the examples as in the real request. If the real email arrives in
<email>tags, so does the email in every example. - Put the real input after the examples, in its own tags. Follow it with the instruction about what to return.
The system prompt is the set of standing instructions sent with every request. Fixed examples can live there, because they're the same every time. The email being sorted goes in the user message.
Instructions still matter. Examples show what you want. A sentence of instruction says why, and that helps on inputs unlike any example. Use both. For instance, write "Refund requests count as billing even when they mention a delivery," and add an example of one.
Note: Every example adds input tokens to every request. Five short examples cost little. Fifty long ones add up across thousands of calls.
Go deeper Examples as a made-up conversation
You'll also see examples written as a pretend earlier conversation. A user message holds an example email. An assistant message holds its category. That pair repeats a few times. Then the real email comes as the final user message. The model sees "its own" earlier answers and tends to keep the same format.
That works too. Tagged examples in a single prompt are easier to read, log and edit, so this course uses them.
In either layout, the last message must be the real user request. Ending on an assistant message is called prefilling: you start the model's reply for it. Current models reject it.
Try it below. The system prompt holds the instructions and examples. The user message holds an email that touches two queues.
Send it. Then delete the refund sentence and the examples from the system prompt, and send again. If a reply comes back cut off, raise max_tokens, the limit on reply length.
Building the prompt in code
In an app, examples usually live in a list of dictionaries. They're often taken from real past cases. A loop turns them into the tagged text:
examples = [
{"email": "I was charged twice for order 5521.", "category": "billing"},
{"email": "Tracking says delivered but there's nothing on my porch.", "category": "shipping"},
{"email": "The jacket arrived with a torn seam.", "category": "product"},
{"email": "Do you have a store in Denver?", "category": "other"},
]
blocks = []
for ex in examples:
blocks.append(f"<example>\n<email>{ex['email']}</email>\n<category>{ex['category']}</category>\n</example>")
examples_text = "\n".join(blocks)
new_email = "Can I swap my order to a different color before it ships?"
prompt = f"""Route the support email to one queue: billing, shipping, product or other.
<examples>
{examples_text}
</examples>
<email>{new_email}</email>
Reply with the queue name only."""
print(prompt)Here's what happened. Each pass of the loop builds one <example> block from one dictionary. Then "\n".join(blocks) glues the blocks together, with a line break between each pair. Last, the f-string drops the examples and the new email into place.
Keeping examples as data has a practical benefit. Say the model gets a case wrong in testing. You add that case, correctly labeled, to the list. Every future prompt then includes it.
examples = [("Great!", "positive"), ("Awful.", "negative")] prompt = "\n".join(f"{t} -> {l}" for t, l in examples) print(prompt.count("->"))
Show the answer
2
The join makes one line per example, so "->" appears twice and count gives 2. Building the prompt in code keeps the format exactly the same every time.
<example> blocks does the printed prompt contain?Show the answer
4
The list holds four dictionaries, and the loop makes one block for each. The new email isn't an example. It sits in its own <email> tags after </examples>.
Worked example: examples for a house style
Few-shot isn't only for labels. Here, past subject lines carry a style. Describing that style in words would take a paragraph.
import requests past_subject_lines = [ "Rain jackets, 30% off, through Sunday", "New: the Ridgeline Fleece is here", "Your boots called. They want a trail.", ] lines = "\n".join(past_subject_lines) prompt = f"""Write one subject line for the email described below, in the same style as our past subject lines. <past_subject_lines> {lines} </past_subject_lines> <email_summary> Free shipping on every order over $50, this weekend only. </email_summary> Reply with the subject line only.""" response = requests.post( "https://api.anthropic.com/v1/messages", headers={"x-api-key": "added-by-the-academy-server", "anthropic-version": "2026-10-21"}, json={"model": "claude-opus-5-5", "max_tokens": 1000, "messages": [{"role": "user", "content": prompt}]}, timeout=60, ) response.raise_for_status() for block in response.json()["content"]: if block["type"] == "text": print(block["text"])
The examples carry the style. They're short and concrete. They use capitals only where a normal sentence would. They have no exclamation marks, and now and then one is playful.
Notice that they vary: an offer, a launch and a joke. Three discount lines in a row would teach the model that every subject line leads with a percentage.
You could also describe the voice in a sentence, such as "plain and concrete, playful at most once in a while." That would help with emails unlike any of the three.
shipping. You want it in product. What's the most direct fix?Show the answer
Add an exchange-for-size email labeled product to the examples, and a sentence saying size exchanges are product
Show the failing case with the right label, and state the rule. Removing the shipping examples would break real shipping emails.
Practice what you just read
- 2 code examples you can edit and run
- a practice exercise that checks your code
- a 5-question quiz
- 5 review cards for spaced repetition
Try a quiz question
When do examples help more than adding more instructions?