Skip to content
Working with the tools, not about them

Prompt Craft

Two worked examples teach a format that a page of rules will not

Rules describe the edges of what you will accept, examples describe the middle of it, and for anything with a shape the middle is what you actually needed to communicate.

By Devika Menon4 min read

Editorial note. Independent reporting and analysis. Nothing here is sponsored or paid for. How we work.

Rules describe a boundary, an example describes a target

Write out the rules for a good product description and you will produce something like: keep it under sixty words, avoid superlatives, lead with the material, mention the fit. Every one of those is true and every one of them describes a limit rather than a destination. An enormous number of dull, technically compliant descriptions satisfy all four.

Now paste in two descriptions you actually liked. You have communicated rhythm, where the sentence breaks fall, how specific the material detail goes, whether the fit note comes as a clause or a separate line — a dozen things you would not have thought to write down and could not have written down quickly.

This is why the effort of assembling examples usually beats the effort of refining wording. You are not explaining your taste, which is slow and lossy. You are showing it, and letting the pattern-matching do what it is good at.

One example gets copied, including its accidents

A single example is dangerous in a specific way: everything in it looks load-bearing. If your one sample happens to open with a date, outputs will open with a date. If it mentions a colour, every subsequent one will mention a colour, whether or not the item has a notable colour. The tool cannot tell which features were the point.

Two examples that differ in the right places fix this cheaply. Where they agree, the pattern is fixed and gets reproduced. Where they diverge, the tool infers that this is a slot that varies with the input. You are effectively drawing a line through two points instead of guessing a line through one.

A third example earns its place when there is a case that behaves differently — the item with no material to name, the record with a field missing, the short version. That third one is doing a job the other two cannot, which is a better reason to include it than the vague sense that more is better.

Choosing the examples is where the work actually is

The instinct is to reach for your best-ever output, and it is usually the wrong pick. Exceptional pieces are exceptional partly because of things that will not recur, and those idiosyncrasies get transmitted along with everything else. A representative example that you would be content to receive is more useful than a brilliant one you got lucky with.

Trim them, too. Anything in an example that you do not want reproduced should come out, including formatting artefacts, stray line breaks and an unusual bit of punctuation. Whatever is in there is being taught, and it is being taught more forcefully than anything you say about it in prose.

Where you have a genuine house style, a small set of examples functions as the style guide better than the style guide does. It ages differently as well: updating one example changes behaviour immediately, whereas amending a rule in a long document may or may not change anything.

What examples are bad at

They transmit form far better than judgement. Show two well-argued paragraphs and you will get paragraphs with the shape of an argument, which is not the same as an argument that holds. Anything requiring domain knowledge the tool does not have will come back looking right and being empty, and examples make that failure harder to spot rather than easier.

They also narrow output, sometimes more than you wanted. Feed three examples of a certain rhythm and you will get that rhythm indefinitely, including where a different one would have served better. For repeatable production work that is precisely the point. For anything where you wanted range, examples are working against you.

And a practical cost: examples consume room in the input, which matters when the actual source material is long. Two tight examples are usually better than five sprawling ones, both for that reason and because five inconsistent samples teach an inconsistent pattern.

Rules and examples do different jobs, so use both

The division that works in practice is to show the shape and state the exceptions. Examples carry format, length, register and level of detail. Written rules carry the things an example cannot demonstrate: what to do when a field is empty, what must never be inferred, when to stop and say the source does not support a claim.

A counter-example is worth more than a prohibition when a specific failure keeps recurring. Showing a rejected version alongside a corrected one communicates the distinction far more precisely than an adjective, because you have marked the exact difference rather than gesturing at a quality.

None of this is a trick. It is the way you would brief a capable new colleague who cannot ask follow-up questions: here are two we were happy with, here is one we sent back, here is the rule for the odd case. The fact that it works on a tool as well says something about how much of briefing was always pattern transfer.

Common questions

Do examples need to be real, or can I write ideal ones?

Written ones are fine and often better, because you can strip out the accidents that a real sample carries. The risk is writing something you cannot actually produce consistently, which sets an expectation the rest of your process will not meet. If you invent an example, make sure it is one you would genuinely be happy to receive back.

Where should examples go in the instruction?

Close to the task and clearly marked as examples rather than as material to work from, which is the common accident. Label the input and output halves explicitly. If your source material is also long, keeping the examples adjacent to the instruction rather than buried in the middle of the input tends to help.

My outputs are all starting to sound the same. Is that the examples?

Almost certainly, and it is the mechanism working as designed. If you want variety, either reduce to one example and lean on written constraints, or deliberately supply examples that differ in the dimension you want to vary. You cannot have tight consistency and range from the same set of samples.

Prompt Craftexamplespromptingformatconsistency
Devika Menon
Reporter, Prompt After Prompt

Devika has been reporting on prompt craft, writing with ai, images & audio since long before it was fashionable and reads the small print so you do not have to.

Prompt Craft

Give it the brief, not the archive

Supplying background is a selection problem, and the instinct to include everything relevant produces worse…

· 3 min read