One example beats a paragraph of description
Here is a prompt that does almost everything right — a real task, a named audience, a stated format, an explicit constraint:
Write a launch post announcing Acme Sync. ### Audience Frontend developers at small startups. ### Context Acme Sync keeps Figma files and production code in step. ### Requirements - Length: About 600 words. - Output format: Markdown, with a heading per section. - Avoid: marketing superlatives.
Instant checks
States a concrete task
PassedAvoids vague language
PassedSpecifies an output format
PassedGives context or audience
PassedAvoids dangling references
PassedIncludes an example
ConsiderNo example of the output you want.
Recommendation — One worked example pins down format, tone, and edge-case handling far more reliably than describing them in prose.Separates data from instructions
PassedAvoids over-aggressive phrasing
PassedDefines what a good answer looks like
Passed
You will get a decent launch post from this. You will also get a headline in a register you did not want, sections in an order you would not have chosen, and an opening line that is a paragraph long when you wanted a sentence.
None of that is disobedience. You never said.
Description is a lossy encoding of a format
Try describing, purely in words, exactly what you want a headline to look like. Tone, length, whether it is a question, whether it names the product, whether it uses a colon. You can do it — in about four sentences that are tedious to write and tedious for the model to weigh against each other.
Or you can show one headline, and every one of those decisions is settled at once.
This is what few-shot prompting actually is. Not a trick, not a technique with a name to memorize. Just the observation that showing is a denser encoding than telling, for anything with structure.
What an example pins down that prose cannot
Register. The difference between "Introducing Acme Sync" and "Your designer changed the button. You found out in code review." is not describable in a constraint. It is immediately obvious in an example.
Structure. Where the heading goes, whether there is a subtitle, how long a section runs before the next one.
Edge cases. What happens with an empty field, a missing value, a name with an apostrophe. One example containing the awkward case resolves it permanently.
Density. How much detail per bullet. This is nearly impossible to specify and trivial to demonstrate.
Write a launch post announcing Acme Sync. ### Audience Frontend developers at small startups who have lost work to version mismatches. ### Context Acme Sync keeps Figma files and production code in step. Nobody in the audience has heard of it. ### Requirements - Length: About 600 words. - Output format: Markdown, with a heading per section. - Avoid: marketing superlatives. ### Example of the wanted output ## Title Opening line naming the specific pain.
Instant checks
States a concrete task
PassedAvoids vague language
PassedSpecifies an output format
PassedGives context or audience
PassedAvoids dangling references
PassedIncludes an example
PassedSeparates data from instructions
PassedAvoids over-aggressive phrasing
PassedDefines what a good answer looks like
Passed
Those four lines do more than the four sentences you would otherwise have written — and unlike a description, they cannot be misread.
How to write one that works
One is usually enough. The instinct to provide five is mostly wasted effort. One good example fixes the format; the second and third rarely change the output.
Make it a real example, not a schema. ## Title followed by an actual opening line beats ## [Your title here]. Placeholders teach the model to produce placeholders.
Include the hard case. If your data sometimes has a null, put a null in the example. That is where the format decisions you have not thought about are hiding.
Keep it short. An example that is longer than the output you want will distort the length of the answer.
When examples do not help
Our checker applies this rule to writing and extraction, and deliberately not to summarization or open analysis. There is a reason.
For a summarization task, the source material is the example — the model can see the input and infer the register. Demanding an example of a summary is asking for busywork, and a checker that demands busywork gets ignored.
That distinction is the difference between a rule and a ritual. Add an example when the output has a shape you care about. Skip it when the shape is obvious from the input.
Every check in this article ran live in your browser. The same nine run on any prompt you paste in, for free.