Prompt patterns for real tasks

Prompting has a short list of structures that keep reappearing, because they solve the same handful of recurring problems: a model with no memory of your situation, a task that is really several tasks in a trenchcoat, output that has to slot into code, or a first answer that is close but not quite right. This guide is a toolkit, not a lecture. Eight patterns, each with what it is, when to reach for it, and a template you can copy, fill in, and use today. Most real prompts combine two or three of them; few tasks need all eight at once.

1. The anatomy template: role, task, context, format, examples

This is the shape underneath most prompts that work on the first try, and the fastest route from a blank cursor to a usable draft. Five slots, in order: who the model should act as, the task in one sentence, the context it has no way of knowing, the format you want back, and, if the task is picky about shape, one or two examples. Not every slot earns a line every time. A quick internal email needs two of the five; a client-facing report probably needs all five. What matters is running through the five in order, so you notice when you skipped one.

[ROLE]     You are a {role, if a role changes the tone or priorities}.
[TASK]     {one clear sentence: exactly what to produce}
[CONTEXT]  {what the model has no way of knowing: audience, constraints,
            decisions already made}
[FORMAT]   {length, structure, tone, language}
[EXAMPLES] {optional: 1-3 examples of what "good" looks like}

Filled in:
You are a support engineer replying to a frustrated customer.
Write a reply to the message below.
The customer is on the free plan, has emailed twice already, and the
bug is confirmed and fixed in next Friday's release.
Keep it under 120 words. Apologize once. Give the ship date. No
corporate boilerplate.

Message: "This is the third time this export has failed silently.
I need an answer."

2. Few-shot examples

A few-shot prompt puts a small set of input-output pairs in front of the real request, in exactly the format you want the real answer in. Reach for it when the output's shape is easier to show than to describe: an exact schema, a house tone, a classification with fuzzy boundaries, a formatting quirk that would take a paragraph to spell out in words. GPT-3 was shown to pick up new tasks this way, from a handful of examples placed directly in the prompt, with no retraining involved.² Nothing about the model changed between examples; the pattern already sitting in the prompt did the work.

• Use 2 to 3 examples, not 1. A single example teaches its own accidents, an unusual length or a specific word choice, right alongside the real pattern.
• Cover the edge case you actually care about, not just the easy, obvious case.
• Keep every example in the exact same wrapper as the real input. A mismatched shape breaks the pattern the model is completing.

Classify the support ticket priority as low, medium, or high.

Ticket: "Login button is a slightly different shade of blue on mobile."
Priority: low

Ticket: "Can't reset my password, the reset email never arrives."
Priority: medium

Ticket: "Production is returning 500s for all customers."
Priority: high

Ticket: "{the real ticket text goes here}"
Priority:

3. Step-by-step reasoning for multi-step problems

Save this for tasks with real intermediate steps: arithmetic with several stages, a decision that weighs more than one factor, logic with more than one condition. Skip it on a simple lookup or a one-line rewrite, where it adds tokens without adding accuracy. The paper that popularized the technique found consistent gains on multi-step arithmetic, commonsense, and symbolic reasoning tasks, and specifically in sufficiently large models (the effect is weak or absent in small ones).³ The template is one line, because the pattern itself is simple: {task}. Work through it step by step, then give the final answer on its own line labeled "Answer:". The label matters almost as much as the request for steps. Without it, you have to read through prose to find the number you actually wanted.

4. Task decomposition

Some asks are not one task, they are three or four tasks wearing a trenchcoat, with a dependency order between them. Asking for all of it in a single instruction pushes the model to compress or skip a step. Decomposition means naming each sub-task, writing one prompt per sub-task (each with its own anatomy template), and feeding each output into the next step as context. Anthropic's own guidance makes a similar case for chaining prompts explicitly: it costs a little speed, and buys you the ability to inspect, log, or fix one step in a pipeline instead of the whole thing at once.¹

1. 1List every sub-task the big ask actually requires, in the order each one depends on the last.
2. 2Write one prompt per sub-task, each with its own role, task, context, and format.
3. 3Feed the previous step's output into the next step as context, not just as background color.
4. 4Check the final output against a rubric (pattern 8) before calling the chain done.

• A rough transcript into a blog post: extract the key points, then outline, then draft, then edit for voice.
• A pile of documents into a decision: gather the sources, list the options, weigh each one, then recommend.
• A messy CSV into a report: extract the fields, validate them against your rules, then summarize what passed and what did not.

5. Structured extraction: output-to-schema

When the output has to feed straight into code, prose is the wrong shape no matter how well it reads. Structured extraction means specifying the exact schema, field names, types, and what to do about missing data, before showing the model the input, so it fills a shape you already defined instead of inventing one on the fly.

Extract the following fields from the input as JSON. Use exactly
these field names. If a field is not present in the input, use null.
Return only the JSON object, no other text.

Fields:
- customer_name (string)
- issue_summary (string, one sentence)
- priority ("low" | "medium" | "high")
- mentioned_date (string, YYYY-MM-DD, or null)

Input: "Hi, this is Dana Reyes. My export has failed three times
since Tuesday. This is urgent, I have a board meeting Friday."

Two details carry most of the weight here: naming the exact field names instead of describing them in prose, and stating the fallback for missing data instead of leaving the model to guess. Both remove a decision the model would otherwise make on your behalf, and make differently on every run.

6. Delimiters: separate instructions from input data

Any prompt that mixes an instruction with a block of pasted data has a seam, the point where the model has to work out which part is the command and which part is content to act on. Delimiters mark that seam. It matters more than it looks: pasted data is just more tokens sitting in the same prompt, and without a marked boundary, an instruction-shaped sentence sitting inside the data can get read as an instruction, or the last line of your own instructions can get read as part of the data. Anthropic's prompting documentation recommends the same fix: wrap each kind of content, instructions, context, input, in its own tag, and stay consistent about which tag means what.¹

• XML-style tags, <instructions>...</instructions> and <input>...</input>. The tag name doubles as a label you can point back to: "summarize the text in <input>."
• Triple quotes or code fences around the data block, with instructions above or below it, never interleaved with it.
• A plain header line, INPUT:, with nothing else on that line, followed by the data.

7. Self-critique then revise

A first answer is usually most of the way there. Instead of accepting it as is or rewriting it yourself by hand, ask the model to check its own work against specific criteria, then produce a revised version. This works because judging an existing answer against stated criteria is a narrower, easier problem than producing a good answer from nothing, so a second pass catches things the first pass missed.

Step 1, draft:
{your task prompt}

Step 2, critique:
Review the answer above against this checklist:
- Does it answer the actual question that was asked?
- Is every claim supported by the input, with nothing invented?
- Does it follow the requested format?
List every item that fails, with the specific problem. If nothing
fails, respond with "PASS" and nothing else.

Step 3, revise (only if step 2 found problems):
Revise the answer to fix every item listed above. Leave everything
else unchanged.

The detail that makes this work is specific, checkable criteria in the critique step. "Is this good?" invites a vague, reassuring answer. A checklist forces the model to check something falsifiable, which is what turns the revision into a real fix instead of a cosmetic rewording.

8. Rubric / acceptance criteria the model checks itself against

A rubric is the critique checklist promoted to a first-class part of the prompt, written before generation instead of after it. Rather than asking the model to judge quality in the abstract once it is done, you hand it a specific, checkable list of what "done" means up front, and ask it to verify its own answer against that list before handing the answer back to you.

• Write each rubric item as pass or fail, not an open-ended quality judgment. "Does the summary state the deadline?" is checkable. "Is it good?" is not.
• Put the rubric in the same prompt as the task, so it shapes the draft, not just a review pass that happens after the draft already exists.
• Ask the model to show the check, item by item, before the final answer. That makes a false pass visible to you, not only to the model.

Template: {task}. Before answering, check your answer against: {criterion one}; {criterion two}; {criterion three}. Show the check as a short list, then the final answer.