Prompt Patterns Catalog: 15 Reusable Templates for Common LLM Tasks

Every time you sit down to write a prompt, you are solving a problem someone has already solved. Classification, extraction, summarization, comparison, rewriting -- these tasks show up in every LLM project, and the prompt structures that work for them are well-established. If you are new to prompting, start with our Prompt Engineering Basics tutorial first. I keep a personal catalog of 15 patterns that I copy-paste and adapt, and this tutorial gives you that catalog with runnable Python templates.

A prompt pattern is a reusable template structure for a specific type of LLM task. Instead of crafting every prompt from a blank page, you start with a proven skeleton and fill in your specifics. The same way a software engineer reaches for design patterns (factory, observer, strategy), a prompt engineer reaches for prompt patterns.

I used to write every prompt ad hoc. The classification prompt for one project looked nothing like the classification prompt for the next. When I started standardizing them, three things happened: my prompts got more consistent, I stopped forgetting critical instructions, and new team members could contribute prompts on day one because the patterns were documented.

We will group the 15 patterns into four categories based on the type of work the LLM is doing:

Analysis patterns ask the LLM to examine input data and produce structured judgments. These are the workhorses of production AI systems — think content moderation, resume parsing, product review analysis, and document triage.

Classification assigns one or more labels from a fixed set to a piece of text. The critical detail most people miss: you must list the exact labels. If you say "classify the sentiment," the LLM invents its own labels and you get inconsistent results across calls.

I use extraction constantly for parsing emails, invoices, job postings, and log files. The pattern pulls specific fields out of unstructured text and returns them as structured key-value pairs. The key detail: specify each field's expected format (dates as YYYY-MM-DD, names as comma-separated). Without format specs, the LLM picks its own format and you spend the next hour writing regex to normalize the output.

This pattern asks the LLM to score or grade content against explicit criteria. Without criteria, you get vague feedback. With criteria, you get structured, reproducible assessments.

The comparison pattern structures the LLM's analysis when it needs to weigh two or more options. Without structure, comparisons tend to ramble. This template forces a consistent format that is easy to parse programmatically.

Generation patterns ask the LLM to produce new text based on inputs. The biggest mistake I see with generation prompts is under-constraining the output. Without explicit length, format, and style constraints, you get wildly inconsistent results.

Summarization compresses long text into a shorter version. The template controls three things that matter most: target length, audience, and what to prioritize.

This pattern generates question-answer pairs from source material. I reach for it when building training data, study guides, or FAQ sections. The difficulty parameter makes a real difference — without it, you get all easy questions or all hard ones.

Code generation is where under-constraining hurts the most. A bare prompt like "write a function to parse CSV" produces code that technically runs but skips type hints, error handling, and documentation. The comparison below shows the difference: a constrained prompt is only 150 characters longer but eliminates multiple rounds of follow-up.

The full template below bakes these constraints into a reusable function. It accepts the task description, target language, a list of requirements, and optional style notes. The function assembles them into a prompt that asks for type hints, docstrings, error handling, and a usage example.

Rewriting transforms existing text while preserving its meaning. The rewriting pattern works for tone shifts, simplification, formalization, and localization. The constraint that catches most edge cases: "preserve all factual claims."

Reasoning patterns guide how the LLM thinks, not just what it produces. These are the patterns that separate mediocre prompts from excellent ones. Research by Wei et al. (2022) showed that chain-of-thought prompting significantly improves accuracy on arithmetic, commonsense, and symbolic reasoning tasks. If you want the LLM to return structured JSON instead of free text, pair these patterns with Structured Output techniques.

Chain-of-thought (CoT) prompting asks the model to show its reasoning before giving a final answer. This genuinely improves accuracy on math, logic, and multi-step problems -- not just transparency. For a deep dive into CoT variants including zero-shot CoT and self-consistency, see our Chain-of-Thought Prompting tutorial.

The structured steps (identify, determine, work through, state) are not just cosmetic. They prevent the model from jumping to an answer before fully processing the problem. In my experience, the more specific your reasoning steps are to the domain, the better the output.

Where chain-of-thought asks the LLM to reason, step-by-step asks it to produce a procedure. The output is an ordered set of actions someone can follow. This pattern works best when the task has a clear sequence and each step depends on the previous one.

How many times have you asked an LLM "what are the pros and cons of X?" and gotten a generic, surface-level list? The fix is anchoring the analysis to a specific context and forcing a verdict. Without context, you get textbook answers. With context, you get actionable advice.

Few-shot prompting gives the LLM examples of the input-output mapping you want. Instead of describing the format in words, you show it. I use this more than any other pattern because it is the most reliable way to control output format. For zero-shot vs. few-shot tradeoffs, see our Zero-Shot and Few-Shot Prompting guide.

Transformation patterns change the form or perspective of content without losing its core meaning. These are simpler than they look, but the details in the template — preserving formatting, handling ambiguity, maintaining consistency — make the difference between usable and unusable output.

Translation goes beyond language — it includes translating between formats, registers (formal to casual), or technical levels. The key constraint most people forget: "preserve formatting." Without it, the LLM strips bullet points, code blocks, and headers during translation.

Data transformation converts structured data from one format to another — CSV to JSON, flat to nested, raw to aggregated. This is one of those patterns where showing the LLM the desired output schema is more effective than describing it in words.

The persona pattern sets the LLM's expertise, communication style, and constraints for an entire conversation. It is essentially a system prompt builder -- see our System Prompt Engineering tutorial for advanced techniques. I separate it from the other patterns because it shapes all subsequent prompts rather than producing a one-off output.

F-string templates work for individual patterns, but real projects combine multiple patterns into complex prompts. A classification prompt might need few-shot examples and chain-of-thought reasoning. Jinja2 handles this composition cleanly with conditionals and loops.

The template below builds a content moderation classifier that combines three patterns at once: persona (setting the role), few-shot (providing labeled examples), and chain-of-thought (forcing step-by-step reasoning). Jinja2 {% if %} blocks let you toggle each feature on and off without maintaining separate template strings.

In production, you rarely create templates one at a time. A template factory pre-configures defaults for a specific use case and returns a callable that only needs the variable parts. The create_template function below stores three pattern types (classify, extract, summarize) as Jinja2 templates and returns a render function with your defaults baked in.

Real projects rarely use a single prompt in isolation. A customer support pipeline might classify a ticket, extract key entities, then generate a draft response -- three patterns in sequence where each step feeds the next. This is prompt chaining, and it is the most common pattern in production LLM systems.

A prompt pattern is only as good as its consistency. The same pattern can produce excellent results on one input and hallucinate on another. Before deploying any pattern to production, build a small test set and measure how often the output matches your expectations.

This harness tests the prompt structure, not the LLM output. That is deliberate -- you can validate that your template includes the right labels, constraints, and input text without burning API tokens. For end-to-end evaluation including LLM responses, see our Prompt Evaluation Pipeline tutorial.

This table lists all 15 patterns with their purpose and the single most important constraint for each. When starting a new LLM task, scan the "Purpose" column to find your pattern, then check the "Key Constraint" column for the detail that makes or breaks the output quality.

Prompt patterns are not magic — they fail if you misapply them. These are the mistakes I have seen most often across teams and projects.

The second mistake is using chain-of-thought for simple tasks. If you ask "What is the capital of France?" with a full CoT prompt, you waste tokens and sometimes get worse results because the model overthinks a trivial question. Reserve CoT for multi-step reasoning, math, and logic problems.

The third common trap is hardcoding context that should be a parameter. If your summarization prompt says "summarize in 3 sentences," that number should be a variable. Every fixed value in a prompt is a future refactoring task when requirements change. For enforcing consistent output shapes beyond plain text, see Structured Output from LLMs.

Which pattern should I start with for a new LLM project?

Start with classification and extraction — they cover the majority of structured LLM tasks and are the easiest to evaluate. You can verify classification accuracy with a labeled test set and extraction correctness by checking field values against source data.

Do these patterns work with every LLM provider?

Yes. The patterns are model-agnostic. I have used them with OpenAI, Anthropic Claude, Google Gemini, and local models through Ollama. You may need to adjust the strictness of format instructions -- smaller models sometimes need more explicit output constraints. The example below shows how the same classification pattern produces an identical prompt string regardless of which provider you plan to call.

Can I combine more than two patterns in one prompt?

Yes, but be deliberate about it. The Jinja2 composite template in this tutorial combines persona + few-shot + CoT. Beyond three patterns in a single prompt, the instructions tend to conflict or confuse the model. If you need more complexity, split into a multi-turn conversation where each turn uses one pattern.

Should I use f-strings or Jinja2 for my templates?

For prototyping and single-purpose prompts, f-strings are simpler and faster to write. Switch to Jinja2 when you need conditional sections, loops over variable-length data, or when multiple team members are editing prompts. Most production systems I have worked on end up using Jinja2 within six months.

All 15 prompt pattern functions in a single runnable script. Copy this into your project as a prompt_patterns.py module.

You now have 15 reusable patterns and the tools to combine, chain, and test them. Here is where to go from here based on what you want to build:

For prompting depth: System Prompt Engineering → Chain-of-Thought Prompting → Structured Output → Prompt Evaluation Pipeline. For application building: First AI App → OpenAI API → LangChain Quickstart → RAG from Scratch.