Prompt Design Patterns: A Reusable Library for Better LLM Output

Strong prompts are not written — they are designed. The best teams build a library of reusable prompt patterns that encode how their models should reason, what format output should take, and how to handle edge cases. This guide covers the core patterns — templates, few-shot, chain-of-thought, and structured output — and how to assemble them into a library your whole team can reuse instead of reinventing.

A prompt pattern is a repeatable structure with proven behavior. Learn the patterns once, then combine them for most of the tasks you will face.

Template pattern: parameters over prose

A prompt template fixes the instructions and leaves slots for the variables: the task, the input, and any constraints. Templates prevent drift — every generation uses the same instruction wording, so changes are intentional and reviewable. Keep templates thin: instructions that rarely change, not a paragraph of prose with placeholders sprinkled through. Delimit variable content clearly so the model can tell instruction from data.

Few-shot pattern: examples over explanations

For tasks where the model must imitate a style, a format, or a reasoning step, three to five examples beat a paragraph of description. Choose examples that cover the edges: one short input, one long input, one that should be rejected. Place examples directly before the live input so they stay in the model's attention window, and label them explicitly — Input and Output headers — rather than relying on formatting alone.

• Start with 3 to 5 diverse examples covering normal and edge cases.
• Put examples immediately before the live input.
• Include one negative example that shows what not to do.

Chain-of-thought pattern: make the model show its work

For math, multi-step logic, and extraction tasks, asking the model to reason step by step before answering measurably improves accuracy. Force the structure with an instruction like 'show your reasoning, then give a final answer' so you can discard the reasoning and act only on the result. On cost-sensitive paths, prune the reasoning afterward — many models keep most of the accuracy gain from a short reasoning scaffold at a fraction of the token bill.

1. Ask the model to list the steps it will take.
2. Have it complete each step explicitly.
3. Request a final answer in a fixed format you can parse.

Structured output pattern: schemas over sentences

When a downstream system consumes the result, ask for JSON or XML against a schema instead of free text. Name the fields, give their types, and specify the allowed enum values for categorical fields. Combined with a validator that rejects malformed or out-of-range output, this turns the model into a reliable data layer rather than a text generator you have to parse with fragile heuristics.

• Define the JSON schema, field types, and allowed enum values.
• Request strict output and validate every response on receipt.
• Surface validator failures visibly instead of letting them fail silently.

Building your pattern library

Store patterns as versioned files with a name, a stated purpose, and a test case — not as chat history. Each entry should record when to use the pattern, the parameters it takes, and one example invocation. Review patterns like code: require every change to be accompanied by a changed sample output. Rotate ownership so the library reflects what the team actually uses, and archive patterns that no team has adopted within a quarter.

FAQ