← All guides

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:

Well-specified, no example
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

9 key structural practices evaluated locally

89% Coverage8/9
  • States a concrete task

    Passed
  • Avoids vague language

    Passed
  • Specifies an output format

    Passed
  • Gives context or audience

    Passed
  • Avoids dangling references

    Passed
  • Includes an example

    Consider

    No 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

    Passed
  • Avoids over-aggressive phrasing

    Passed
  • Defines what a good answer looks like

    Passed
One check fails — and it is the cheapest one to fix.

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.

The same prompt, plus four lines of example
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

9 key structural practices evaluated locally

100% Coverage9/9
  • States a concrete task

    Passed
  • Avoids vague language

    Passed
  • Specifies an output format

    Passed
  • Gives context or audience

    Passed
  • Avoids dangling references

    Passed
  • Includes an example

    Passed
  • Separates data from instructions

    Passed
  • Avoids over-aggressive phrasing

    Passed
  • Defines what a good answer looks like

    Passed
Every applicable check passes.

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.