Mastery Module 12 · The Prompting Playbook

Show, Don't Tell

Last reviewed

Intermediate

What you'll learn

~14 min
  • Replace hard-to-describe instructions with examples the model can pattern-match
  • Write examples that are consistent, varied, and include the hard cases
  • Recognize when examples lock in a format you did not intend

You already know to use examples — Module 10 listed them as one of the five elements of a good prompt. This lesson is about doing it the way the Claude team does it, because examples are the single most reliable way to control output, and most people write them badly.

The principle, stated plainly: for anything with a consistent shape, a few examples beat any description. This is called multishot (or few-shot) prompting. You are not explaining the pattern — you are demonstrating it and letting the model match it.

Describing vs. demonstrating

Say you want product feedback turned into structured tickets. You could describe it:

Convert each piece of feedback into a ticket. Include a short title,
a priority, the affected area, and a one-line summary. Make the title
imperative and keep the summary factual…

…and you will get something close, but the priority labels will drift, the title style will wander, and the area names will be inconsistent. Now demonstrate instead:

Convert each piece of feedback into a ticket, following these examples exactly:
Feedback: "The app logged me out in the middle of checkout and I lost my cart."
Ticket:
Title: Preserve cart across session expiry
Priority: High
Area: Checkout
Summary: Session timeout during checkout discards the cart.
Feedback: "Love the new dashboard but the export button is hard to find."
Ticket:
Title: Increase visibility of dashboard export
Priority: Low
Area: Dashboard
Summary: Export action is not discoverable in the new dashboard layout.
Now convert this feedback:
"Search returns results from deleted projects, which is confusing."

The model now has the exact title voice (imperative), the priority vocabulary (High/Low, not “urgent”/“minor”), the area naming, and the summary register — locked in by demonstration, not description.

Three rules for examples that work

1. Be consistent. The model copies whatever pattern your examples share — including mistakes. If one example says Priority: High and another says priority: high, you have taught it that casing is optional. Every example should look exactly the way you want the output to look.

2. Cover the variety, not just the easy case. If every example is a simple, clean input, the model learns to handle simple, clean inputs. Include the awkward ones — the ambiguous feedback, the multi-issue report, the edge case — so the pattern holds when real input arrives.

3. Show the hard decision, including refusals. If there is a case where the right answer is “none” or “needs human review,” include an example of that. Otherwise the model assumes every input must produce a confident result and will force one.

Feedback: "asdkjfh"
Ticket:
Title: —
Priority: —
Area: Needs triage
Summary: Unintelligible input; route to a human.
💡How many examples?

Two or three is usually the sweet spot for a format. More helps when the task is genuinely varied (classification with many categories, edge-case-heavy parsing) — but each example costs context. Start with two or three good, varied examples; add more only if the pattern is still slipping. One example often beats zero by a wide margin; the jump from one to three is where consistency locks in.

The most common mistake: examples that disagree with each other

When output drifts despite examples, the cause is almost always that the examples are not actually consistent. The model is matching the pattern faithfully — the pattern just contains contradictions you did not notice.

Before you add a fourth example, reread the three you have and ask: does any detail vary between them that I do not want to vary? Spacing, label casing, punctuation, ordering, level of detail. The model treats every difference as meaningful.

📊In Your Field: MIS / Businessclick to expand

Examples standardize reports. Pasting two finished example reports — the exact section order, the way KPIs are phrased, how variances are flagged — produces far more consistent monthly reporting than a written spec ever will. Your past good reports are your prompt.

🎧In Your Field: Music Producerclick to expand

Examples capture your voice. Drop in three captions you actually wrote and liked, then ask for the next one. The model matches your tone, emoji habits, and hashtag style far better from examples than from “write it in my voice.”

The trap: examples lock in more than you meant

Examples are powerful precisely because the model copies them — which cuts both ways. If all your examples happen to be two sentences long, the model will keep outputs to two sentences even when a case needs more. If every example is positive, it may struggle to produce a negative one.

Two ways this bites:

  • Format lock-in. Your examples become a hard mold. If you later want a different shape, change the examples, not just the instructions — the examples win when they conflict with the prose.
  • Hidden bias. If your examples skew one way (all high-priority, all one category), the model inherits that skew. Vary them deliberately.
KNOWLEDGE CHECK

Your few-shot prompt keeps producing inconsistent output despite three examples. What is the most likely fix?

Key takeaways

  • Demonstrate, don’t describe. For anything with a consistent shape, two or three examples beat a paragraph of instructions.
  • Consistency is everything. The model copies the shared pattern in your examples — including any inconsistencies. Make every example look exactly like the output you want.
  • Cover the variety and the hard cases, including “none / needs human” so the model doesn’t force a confident answer onto bad input.
  • Examples lock in format and bias. That’s the power and the trap — when you want different output, change the examples, not just the prose.

Next: Let the Model Think

Search lessons