Prompt Patterns Library

A browsable set of patterns. Each entry is the pattern, the template you can paste, and the boundary that decides whether to trust it on your task. Read the boundary line first.

Chain-of-thought. Ask the model to work through its reasoning before it answers, instead of jumping to a verdict. The classic trigger is a line telling it to think first.

Where it breaks: the explicit "think step by step" instruction earned its reputation on older models that did not reason by default. Newer models often reason internally whether you ask or not, so the line can add tokens and latency without moving accuracy. Treat it as something to test on your model, not a reflex to keep forever.

ReAct (reason then act). The loop pattern behind tool-using agents. The model alternates between a reasoning step and an action step, observing the result of each action before deciding the next. Introduced in the ReAct paper (arxiv 2210.03629), it is the bridge from a single prompt to an agent that does things.

Where it breaks: every step depends on the one before it, so a wrong observation early poisons everything downstream. At 95% reliability per step a ten-step loop lands near 60% end-to-end. The pattern is only as good as your stop condition and your willingness to check the steps, not just the answer.

Few-shot. Show two to five worked examples of the input-to-output mapping you want, then give the real input. Examples beat explanations when you want a specific shape, tone, or edge-case handling. One good demonstration outperforms a paragraph describing the rule.

Where it breaks: this is the pattern with the sharpest cliff, so it gets the worked example below. More examples is not strictly better. A routing task on Gemini 3 Flash scored 93% at zero-shot, climbed as examples were added, then collapsed to 30% at eight examples; Qwen 3.5 fell from 56% to 0% on a code-fixing task once more examples piled on.

Order matters too. Changing only the order of the same examples swung sentiment accuracy from 54% to 93% in the Calibrate-Before-Use study (Zhao et al., arxiv 2102.09690), because the model over-repeats whichever label sits last. And position swings it again. Relocating an identical demo block from the start to the end of the prompt moved accuracy by 20 to 50 points with no content change (DPP, arxiv 2507.22887), with demos placed before the query reliably more stable. So few-shot is a precision instrument, not a volume knob. Use a few balanced, boundary-spanning examples, place them before the task, and cap the count.

Self-consistency. Run the same reasoning prompt several times at a nonzero temperature, then take the majority answer instead of trusting a single roll. It buys accuracy on problems with one correct answer by averaging out the unlucky paths.

Where it breaks: you pay N times the tokens for one answer. It is worth it only when correctness justifies the cost (a number that feeds a decision) and pointless when any reasonable answer will do (a brainstorm). It also assumes there is a single answer to vote on, so it does nothing for open-ended generation.

Structured output over JSON-begging. When you need machine-readable output, stop writing "return only valid JSON, no markdown" in the prompt and use the model's structured-output or tool-calling mode instead. One production team cut JSON parse errors from 8% to 0.3% by switching from prose instructions to tool-calling. Begging in prose tries to enforce something the model does not guarantee.

Where it breaks: forcing a single pass to both reason and emit strict JSON can degrade the reasoning, because the model spends attention on shape instead of substance. When the answer needs real thinking, let it reason in free text first, then extract the structured fields in a second step. Shape and reasoning compete for the same pass; split them when both matter.

Positive over negative specification. Tell the model the target to hit, not the thing to avoid. "Respond in at most three sentences" beats "don't be verbose." "Only discuss our product" beats "don't mention competitors." Models hit a named target more reliably than they avoid a named hazard.

Where it breaks: it depends on you actually having a target to name. When you genuinely only know what you don't want, you have a specification gap to close first, and a negative rule is a sign you have not decided the positive shape yet.

One job per prompt. Ask for one outcome per call. A prompt told to summarize, translate, score, and reformat in one shot produces mediocre work on all four, because every added instruction competes for attention. The IFScale benchmark found even the best frontier models top out near 68% instruction-following at maximum instruction density, with a bias toward the earlier instructions. Split the jobs.

Where it breaks: splitting into a chain trades one risk for another. Each handoff is a place a wrong output can poison the next step, so the more you decompose, the more you need a checkpoint between stages. One job per prompt is right; naive chaining without a verification gate between links is how the error you split out comes back compounded.

Role / persona. Open with "You are a <role>" to set the model's register, vocabulary, and the slice of knowledge it draws from. Useful for tone and framing.

Where it breaks: a role sets voice, not correctness. It does not make the model meaningfully better at hard reasoning, and an overly creative persona can make output less stable. Reach for it to shape how an answer reads, not to fix whether an answer is right.

The copy-pasteable artifacts here are the templates themselves. The thing that makes them operator-grade rather than a gallery is the boundary line on each. Before you trust any pattern on a real task, run it against three to five fixed inputs, change one thing, and compare. The pattern gives you the shape; that small loop is what tells you it works on your inputs and not just in the example.