Show as well as tell
When words cannot pin down the format or judgement you want, give a few varied, delimited examples, including a hard case.
Questa lezione non è ancora disponibile nella tua lingua; viene mostrata in un'altra lingua (English).
Why it matters
Some things are easier to show than to describe: a house style, a borderline classification, the exact layout of a record. In those cases one or two well-chosen examples do more than a paragraph of instructions. Google's guide recommends including a few examples to show the model the pattern you want, and Anthropic's suggests three to five for best results, wrapped in <example> tags so they are not mistaken for instructions.
Examples are powerful, which is also why they need care. A model copies what it sees, including things you did not mean to teach: if every example is about the same product, or the same length, the output will be too. Google warns that too many examples can make the model over-fit them. Make them varied, keep their format identical, and include at least one hard case, ideally with a note on why it falls where it does. Anthropic's article on context engineering recommends a few diverse, canonical examples rather than a long list of edge cases.
Examples are not always needed. For a simple task, or when the output contract already fixes the form, they add little; OpenAI's advice for reasoning models is to try without examples first and add them when the output is complex. The rubric marks this criterion as not applicable when an example would add nothing.
What good looks like
- 0 — Examples clearly needed, none given. “Classify each support ticket by urgency.” Urgency according to whom?
- 1 — A reference mentioned but not provided. “…like we did last month.” The model was not there last month.
- 2 — One example, or several that all show the same case. The model may over-fit it.
- 3 — Two to five varied examples in a consistent, delimited format. Urgent, normal and low each shown once.
- 4 — Varied examples including an edge case or counter-example, each with a short reason. “‘Cannot log in (one user)’ → normal, not urgent: a single user is affected.”
Common mistakes
- Pointing at examples (“as before”, “like the attached”) without including them.
- Examples that disagree with the instructions, which leaves the model to choose between them.
- All examples alike, so the model copies their length, topic or wording.
- Mixing formats between examples, or not delimiting them from the real input.
- Adding examples by habit to a task that does not need them.
Try it on your own prompt
Paste a prompt into the workspace where the format or judgement matters. Write two examples that differ from each other as much as your real inputs do, and one hard case with a sentence explaining the decision. Wrap them in tags, then compare the examples score and check whether the output follows the pattern without copying it.
Esempi svolti
Routing customer messages
Sort these customer messages into categories like we did before.
Sort each customer message into one category: delivery, billing, product fault or other. Here is how we decide, with a note on why:
<examples>
<example>
Message: "My parcel says delivered but it isn't here."
Category: delivery
Note: the problem is where the item is, not what it is.
</example>
<example>
Message: "I was charged twice for one order."
Category: billing
</example>
<example>
Message: "The kettle arrived with a cracked lid."
Category: product fault
Note: damage on arrival counts as a fault, not a delivery problem, because the replacement comes from the product team.
</example>
<example>
Message: "Do you sell gift cards?"
Category: other
Note: a question, not a problem; there is nothing to fix.
</example>
</examples>
<messages>
{{paste the messages here}}
</messages>
Give one line per message in the form "number: category".
“Like we did before” points at examples the model never saw. The strong version gives four varied, delimited examples, including the borderline damaged-on-arrival case, with the reasoning behind the hard calls.
Product descriptions in house style
Write product descriptions in our brand voice.
Write a product description of 40 to 60 words for each item listed at the end. Match the voice of the two examples: warm, concrete and a little dry, written to the reader as "you".
<example>
Product: linen tea towel
Description: You will use it daily and iron it never. Washed linen dries fast, softens with every wash and does not leave lint on your glasses. It hangs from a cotton loop, and the stripe is woven in, so it will not fade before the towel wears out.
</example>
<example>
Product: cast-iron casserole, 24 cm
Description: Heavy enough to keep a stew at a murmur for hours, light enough to lift with one hand and a tea towel. You can brown on the hob, finish in the oven and serve at the table. It needs no seasoning; it does need a sturdy shelf.
</example>
Not like this, because it is vague and over-excited: "Experience the ultimate in kitchen luxury with this amazing must-have item!"
<items>
{{paste the product list here}}
</items>
A voice is hard to describe and easy to show. Two examples from different product types, plus one counter-example with a reason, let the model match the style without copying any single example.
Esercizio
Add three to five varied examples to this prompt, including at least one hard case, in a consistent, delimited format.
Rewrite this prompt so the examples are actually in it, varied, each with a short note on what makes it work.
Rewrite this prompt with two contrasting example replies and one counter-example that shows what to avoid, and why.