Five Prompt Patterns, Each With a Before and After

Most collections of prompt examples are worthless for a reason that has nothing to do with the quality of the prompts. They are lists of finished artefacts written for tasks that are not yours, so copying one gets you an output shaped like someone else's problem. What transfers is not the text. It is the five or so moves the text is making.

Below are those moves, each with the same task written badly and then well, so you can see what changes in the answer rather than being told it improves. The task is deliberately mundane: turning a customer email into something usable. Every pattern is one you can apply within a minute of reading it.

Pattern one: state the output format

The most common prompt failure is not vagueness about the task. It is silence about the shape of the answer, which the model then has to guess. That single habit, naming the columns you want back, is also the fastest of the habits that change what a chat assistant does for you.

Before: "Summarise this customer email."

After: "Summarise this customer email in exactly three lines: what they want, what they are unhappy about if anything, and what I need to do next. No preamble."

The difference in the output is not subtlety. The first version returns a paragraph of variable length that starts with "This customer is writing to..." and buries the action. The second returns something you can paste into a task list. Anthropic's prompting best practices reference puts this first among its general principles, advising you to be specific about the desired output format and constraints, and to give instructions as numbered steps when the order or completeness matters.

The same page offers a test worth stealing. Show your prompt to a colleague who has no context on the task and ask them to follow it. If they would be confused, the model will be. That reframes prompt writing as a briefing problem rather than a magic words problem, which is what it actually is.

Pattern two: give the reason, not just the rule

An instruction with its motivation attached generalises. An instruction on its own has to be repeated for every case you can think of, and you will not think of all of them.

The example in Anthropic's guidance is the cleanest illustration of this anywhere. The less effective version says "NEVER use ellipses". The more effective version says the response will be read aloud by a text to speech engine, so never use ellipses because the engine will not know how to pronounce them. Same rule, plus the reason.

What the second version buys you is everything you did not write down. A model told why ellipses are a problem also avoids emoji, unusual punctuation, and stage directions in brackets, because it can work out that those fail for the same reason. The first version gets you exactly one rule enforced and nothing else.

Before: "Keep the reply under 80 words."

After: "Keep the reply under 80 words. It goes out as an SMS, so anything longer gets split across messages and arrives out of order."

Pattern three: show, do not describe

Describing the tone you want is much weaker than showing one example of it, and this is the pattern with the most research behind it.

OpenAI's prompt engineering guide defines the technique plainly: few shot learning steers a model toward a new task by including a handful of input and output examples in the prompt, and the guide recommends showing a diverse range of possible inputs alongside the desired outputs. Anthropic's page is more specific about quantity, recommending three to five examples for best results and asking that they be relevant to your actual use case, diverse enough to cover edge cases, and wrapped in example tags so the model can tell them apart from your instructions.

The finding that changes how you write them comes from a peer reviewed study, Rethinking the Role of Demonstrations, by Sewon Min and colleagues. Randomly replacing the labels in the demonstrations barely hurt performance across a range of classification and multiple choice tasks, consistently across twelve models. What the demonstrations actually supply is the label space, the distribution of the input text, and the format of the sequence.

Read that as a practical instruction rather than a curiosity. Your examples are teaching the model the shape of the job, not the answers. So spend your effort on covering the range of inputs you really see, and much less on agonising over whether each example's answer is the perfect one. An example of a difficult, messy input matters more than a flawless answer to an easy one.

Pattern four: fence the input

When your prompt contains both instructions and content, the model has to work out where one ends and the other begins, and it sometimes gets that wrong in ways that look like the model ignoring you.

Before: "Extract the order number from this email: Hi, I still have not had my order, can you check on it, order 44192, thanks."

After: Instructions first, then the email wrapped in a clearly named tag, then the request restated after it.

Anthropic's guidance recommends XML tags for exactly this: wrapping instructions, context, examples and variable input each in their own tag so the model parses a complex prompt unambiguously, with consistent descriptive tag names and nesting where content has a natural hierarchy. OpenAI's guide reaches the same place through a different device, suggesting markdown headers and lists to mark distinct sections, and organising a prompt into identity, instructions, examples and context.

There is a security dimension too, and it is not hypothetical. If the content you are pasting came from a customer, that customer's text can contain instructions. Fencing does not solve prompt injection, but unfenced input makes it trivially easy, and we went through what does help in the piece on defending an agent against prompt injection.

Pattern five: name the role, once

A single sentence of role in the system prompt shifts vocabulary, assumed audience and level of detail across everything that follows, which is a large effect for a small edit.

The trap is doing more of it. Elaborate personas, invented biographies and instructions to act as a world class expert add tokens without adding steering, because the useful signal was in the first clause. "You are writing for the owner of a small shop who has no technical background" does the whole job. Everything after that is decoration you pay for on every request.

Anthropic's reference is explicit that setting a role in the system prompt focuses behaviour and tone, and that even one sentence makes a difference. Note where it says to put it: the system prompt, not the user message. That separation matters more than people assume, because OpenAI's guide describes an explicit authority hierarchy in which developer messages outrank user messages, which in turn outrank assistant responses. An instruction placed at the wrong level competes with the content instead of governing it. We covered what belongs at each level in the piece on what goes in a system prompt and what does not.

The five patterns against the job each one fixes

Different failures need different patterns, and applying the wrong one is why some prompts get longer without getting better.

Where should the long document go in the prompt?

Near the top, above your query and above your instructions. This is the ordering rule most people have backwards, and vendor guidance is unusually direct about it.

Anthropic's reference states it as a rule for long context work: place long documents and inputs near the top of the prompt, above the query, instructions and examples, and says this improves performance across all models. It further recommends wrapping multiple documents in document tags with separate subtags for the content and the source.

The intuition most people carry is the opposite, that the instruction should come first because it is the important part. Putting the question after the material is closer to how you would brief a person handed a stack of paper, and it happens to be what the guidance recommends.

Why did my prompt stop working when I changed model?

Most likely because you moved between a reasoning model and a standard one, and the two want opposite things from you, which is exactly why asking for step by step working now helps only one of them. This is the least advertised breaking change in the whole area.

OpenAI's guide draws the line explicitly: its standard models benefit from precise instructions that spell out the logic and the data required, while its reasoning models work better with high level guidance rather than explicit step by step instructions. So a prompt carefully engineered with a numbered procedure, which is exactly what the first family rewards, can underperform on the second, because you have overridden reasoning the model would have done better itself.

Anthropic's reference reflects the same split from the other side, keeping separate prompting pages per model and noting behavioural differences in verbosity, literal instruction following and tool triggering between generations. There is also a specific note that manual step by step prompting is a fallback for when thinking is off, and that on a current model you should prefer keeping thinking on at a lower effort level instead.

The operational lesson is unglamorous. A prompt is written against a model, not against a task, and a model swap is a change that needs re running your examples. Our note on telling whether a prompt change actually helped covers doing that in a way that survives contact with your own opinion.

Which pattern should you reach for first?

The format one, every time, because it is the cheapest and it exposes whether the rest of the prompt is even the problem.

The diagnostic works like this. Write the format constraint, run the prompt again, and look at what is still wrong. If the answer is now the right shape but the wrong content, the problem was never the prompt structure and no amount of role setting or example stacking will fix it: the model does not have the information. If the answer is the right shape and roughly right content but the wrong register, that is the role pattern or an example. If it is right in every respect except that it quietly ignored one of your constraints, that is the reason pattern, and adding the motivation behind the constraint usually resolves it in one edit.

Working in that order stops the most common failure mode in prompt writing, which is piling every technique into one prompt at once. A prompt carrying a persona, six examples, four format rules and a chain of thought instruction is not five times better than a good short one. It is slower, more expensive on every call, and impossible to reason about when it misbehaves.

There is a cost argument here too. Examples are the only pattern on the list that you pay for on every single request, because they sit in the input on each call. Three to five short examples is a modest overhead. Twenty long ones on a high volume endpoint is a line item, and the piece on why an LLM bill exceeds the estimate covers where those charges accumulate.

What about the hundred prompt lists?

They are useful in exactly one way and misleading in every other. Reading a collection of prompts for a job you have never done shows you which parts of the job people find hard, and that is genuine information about an unfamiliar domain.

What they cannot give you is the specifics, and specifics are the whole difference. A generic prompt for writing a product description produces a generic product description, because the model has no access to the six facts about your product that would make the description worth reading. The pattern is transferable; the content never was. This is the same conclusion the piece on how much editing an AI draft needs reaches from the output side.

There is a second problem with copied prompts that shows up later. When a copied prompt underperforms you have no idea which part is carrying the weight, so you cannot debug it. A prompt you assembled from five known patterns can be taken apart one clause at a time.

Putting them together on one task

Here is the same request built with all five, in the order that works.

The system prompt carries the role: writing for the owner of a small shop with no technical background. The user message starts with the customer email wrapped in its own tag. Under it comes the instruction, stating the three line format and the reason for the length limit. Under that come three short examples covering an easy case, an angry case and an ambiguous one. The query comes last.

That prompt is perhaps fifteen lines. It is not clever, contains no incantations, and no part of it would surprise anyone who has briefed a new colleague. It also does not need to be replaced when your task changes slightly, because each part is doing an identifiable job and you can change one.

If you are wiring prompts into something that runs unattended rather than typing them into a chat box, the format pattern stops being a preference and becomes an enforcement problem, which we covered in how to force a model to hold a schema. And if you want a model to reach your own systems and data rather than only the text you paste, our MCP server page covers the standard interface for that.

The one line version

Stop looking for the right words and start supplying the missing information. Every pattern above is a different piece of context the model did not have: the shape of the answer, the reason for a rule, the range of inputs, the boundary of the content, and who the reader is. Prompting looks like a writing skill and behaves like a briefing skill, and the people who are good at it are the ones who noticed that first.