Two or three real examples beat a paragraph of instructions. Show the edge cases and the refusals, not just the ideal answer.
"Write professionally but warmly, concise but complete, formal but approachable."
Everyone has written a prompt like that, and everyone has been disappointed by
it. Those words mean something different to you than to the model, and there is
no way for either of you to find out where you disagree.
One example of an email you were happy with settles all of it in ten seconds.
Take examples from real work
The best examples are things you actually sent, kept, or approved. Not idealised
versions — the real ones, with the specific level of detail your company uses and
the phrasing your customers are used to.
Two or three is usually enough. Beyond about five, returns fall off quickly and
you start pinning the output to the surface features of your examples.
Show the awkward ones, not just the good ones
This is where most prompts stop too early. If every example is a clean, ideal
case, the model learns to produce clean, ideal answers — including for inputs
that deserve something else.
Include:
- A refusal. An input where the correct answer is "I don't have enough to
answer that", with the response you want. This is the most valuable example in
most skills, and the most commonly missing.
- A partial answer. Where some information was available and some was not,
and the reply says which is which.
- An edge case you get wrong today. Every failure you find becomes an
example, which is how a skill improves over time rather than being rewritten.
A useful ratio: for every three good examples, one refusal and one partial.
Show the input as well as the output
An output on its own teaches style. An input-output pair teaches judgement —
what to do with this kind of material. Always pair them, and make the inputs as
messy as the real ones: the badly formatted note, the email with three questions
buried in it.
Be careful what your examples smuggle in
Examples carry more than you intend. Three specific traps:
Length. If all your examples are four paragraphs, you have specified four
paragraphs, whatever your instructions say about being concise.
Structure. Examples that all start with a summary line will produce a summary
line forever, including where it is silly.
Content. Real examples contain real customer names, prices and personal data.
Anonymise before they go into a shared prompt — a skill everyone can open is a
document everyone can read.
Where the best examples come from
Your own past work is the obvious source. The better one, and the one almost
nobody mines, is what customers actually said — in sales calls, support
tickets, complaints, and the questions they ask before buying.
Two rules make this worth doing:
Keep it near-verbatim. The instinct is to tidy a customer's phrasing into
something more polished. Resist it: the specificity is the value. "The last tool
we tried needed a developer to set it up" is usable in a dozen places. "Ease of
implementation was a concern" is worth nothing, because it could have been said
about anything by anyone.
Tag where and when it came from. A customer quote from two years ago may
describe a problem you have since fixed, and an undated example is one nobody can
judge.
In Belgium, note that recording a conversation and then storing and processing
the transcript are separate questions. Decide who is told, what is kept and for
how long before you build this into a routine — it is a short conversation up
front and an awkward one afterwards.
Where to put them
If several people use the same task, the examples belong in the skill, not in
each person's chat history. That is the difference between one colleague being
good at this and the team being good at it.
Keep them where they can be edited, dated, and reviewed. Examples go stale: a
price changes, a policy changes, and an outdated example is worse than none
because it is followed confidently.
Testing that they helped
Change the examples and run your test set. It is the only way to know.
The common surprise is that adding a fourth and fifth example changes nothing
measurable, while adding the first refusal example changes a lot. Most teams
spend their effort on the first kind.