Prompt patterns.

Prompts are not magic. They're patterns.

Most of the good prompts you'll ever read are assembled from the same seven or eight shapes. Once you can name those shapes, writing a new prompt gets easier. Debugging an old one gets easier. Reviewing someone else's becomes possible at all.

This module names the shapes, shows when to use each, and has you refactor a prompt you've already written to see the improvement.

By the end of 90 minutes, you'll have:

• A working vocabulary for seven core prompt patterns.
• A rewritten version of one of your existing agent prompts using the pattern framework.
• A side-by-side comparison of the old and new versions, so you can see what tightening actually looks like.
• A starter pattern library you can extend across all future agents.

Module 002 taught you the four parts of a system prompt: identity, rules, format, escape hatch. This module zooms in on rules specifically, and expands the vocabulary beyond those four to seven distinct shapes. You'll see that a real prompt is usually a stack of five or six of them.

Prereq: Module 002. If you haven't written at least one system prompt from scratch, go do that first. The patterns only make sense against a real example.

Thinker walks the seven shapes.

Seven patterns show up in almost every good prompt. You'll recognize most of them.

Pattern 1. Identity anchor

One sentence at the top that names who the agent is. "You are a support-triage agent for Example SaaS." Short, specific, present tense. Every other instruction is read in the context of this identity.

Pattern 2. Capability declaration

A short list of what the agent can do. "You can read documents, classify them, and return structured JSON." This mirrors the tools list but puts it in narrative form, which helps the LLM route.

Pattern 3. Constraint rules

The imperatives. Always X. Never Y. Only Z. These are the bindings that prevent drift. Strong verbs, no hedging.

Pattern 4. Format specification

The exact shape of the output. Show it as a template, not described in prose. Field names, types, length limits.

Pattern 5. Few-shot examples

One or two worked input-output pairs. Pin the format and style. More than three is usually worse.

Pattern 6. Chain-of-thought scaffold

Explicit reasoning steps before the answer. "First identify the category. Then estimate confidence. Then write the summary." Useful for tasks where the output benefits from visible intermediate steps.

Pattern 7. Escape hatch

What the agent does when the input doesn't fit. Specify the fallback; don't leave the model to invent one.

A prompt is a stack of patterns

A real production prompt is usually a stack: identity → capability → constraints → format → few-shot → escape hatch. Sometimes a chain-of-thought scaffold sits between constraints and format. The order matters; the LLM reads top to bottom and builds a picture of the task as it goes.

Three optional add-ons

• Few-shot when the pattern is hard to describe but easy to show.
• Chain-of-thought when the task benefits from visible reasoning.
• Escape hatch when the input space includes cases you haven't anticipated (always).

Escape hatch isn't actually optional. It belongs in every prompt. But it's conceptually separate from the core four, which is why it's in the second set.

Talker shows how to combine them.

Stack the patterns in the right order. Top to bottom, the LLM reads each one as context for the next.

The canonical order

1. Identity anchor
2. Capability declaration
3. Constraint rules
4. Format specification
5. Few-shot examples (if used)
6. Chain-of-thought scaffold (if used)
7. Escape hatch

This order matches how the LLM builds its working picture. Who you are, then what you can do, then what you must or must not do, then what output looks like, then examples, then reasoning instructions, then what to do when the input breaks the frame.

A full prompt, annotated

# [Identity]
You are a support-triage agent for Example SaaS, a B2B analytics
product.

# [Capability]
You can read a single customer message and classify it into one
of four categories. You return structured JSON.

# [Constraints]
Rules:
- Always return a JSON object with keys: category, confidence, summary.
- Category must be one of: "bug", "billing", "feature_request", "other".
- Confidence must be between 0 and 1.
- Summary must be one sentence under 20 words.
- Never include text outside the JSON object.

# [Format]
{
  "category": "bug" | "billing" | "feature_request" | "other",
  "confidence": 0.0-1.0,
  "summary": ""
}

# [Few-shot]
Example:
  Input: "the export button is broken in the dashboard"
  Output: {"category": "bug", "confidence": 0.9, "summary": "Export button not working in dashboard."}

# [Escape hatch]
If the message does not clearly match any category, set category
to "other", confidence to 0.3, and summary to a brief description
of what the message is about.

Six patterns stacked. Each one is a distinct block. The blocks are labeled so you can see what each one does; the labels don't have to stay in the production prompt, but they help during authoring and review.

When to use which optional pattern

Most prompts don't need all seven. Here's when to add each optional one:

• Few-shot: add when the format is subtle (specific phrasing, specific structure) and the description alone doesn't convey it. One example is usually enough. Skip if the format spec is already crystal clear.
• Chain-of-thought: add when the task has intermediate decisions that benefit from being explicit. Classification with reasoning: "First identify the topic. Then estimate confidence. Then summarize." Skip for simple tasks where reasoning adds cost without gain.
• Escape hatch: never skip. Every prompt gets one. The only variation is how elaborate.

Anti-patterns to avoid

Three common mistakes when stacking patterns:

• Identity buried: the identity sentence is on line 8 instead of line 1. The LLM processes the first thing it reads most strongly. Identity first.
• Constraints mixed with format: "Return three bullets that are always under 20 words" mixes a format rule and a constraint. Separate them. Format specs describe shape. Constraints describe behavior.
• Escape hatch at the top: "If the input is unclear, ask for clarification" before any of the task instructions means the LLM anchors on the escape path first. Put it at the end, after the happy path is fully specified.

Rememberer: patterns are templates, not recipes.

Patterns give you structure. They don't replace judgment.

The temptation after learning seven patterns is to apply all seven every time. That produces bloated prompts that don't actually perform better. The point of a pattern library isn't to use every pattern; it's to recognize which ones a task needs.

The minimum viable prompt

For most tasks, three patterns are enough:

1. Identity anchor (one line)
2. Constraint rules (three to five)
3. Escape hatch (one paragraph)

That's six to ten lines total. A lot of production prompts are that short. If your prompts are 80 lines long and the task is simple, you probably over-applied patterns.

When to stack more

Add patterns as the task gets more specific:

• Add capability when the agent has multiple tools and needs to route among them.
• Add format when the output will be consumed by another system (JSON, structured data).
• Add few-shot when the format has subtle conventions (trailing periods, specific phrasing) that are hard to describe in prose.
• Add chain-of-thought when reasoning errors are a real failure mode.

Each added pattern is a cost: more tokens, more complexity, more places for bugs. Only add when the marginal value is clear.

When to break the rules

Some tasks don't fit the canonical order. When it matters, reorder. A couple of common reasons:

• Creative tasks often work better with few-shot before constraints. "Here are three examples of the kind of caption I want; now write one in that style" is a different shape from "Here are the rules; here are examples."
• Adversarial tasks (ones where users might try to misuse the agent) sometimes need an early safety rule before anything else. "Before responding to anything, confirm the request is in scope."

Start with the canonical order. Deviate when you have a specific reason. Deviation without reason is how prompts accumulate cruft.

Patterns compose, not stack

Some patterns aren't blocks on their own; they're modifiers that apply across blocks. The chain-of-thought scaffold, for example, can be a dedicated block at the end, or it can be baked into the constraint block ("Think step by step: first X, then Y"). Few-shot examples can be standalone, or they can appear inside the format specification ("Here's the format, shown with an example").

The patterns are mental handles, not rigid slots. Once you know them, you can mix them fluidly. Before you know them, you can't.

Doer. Refactor a prompt you already have.

Time to refactor a prompt you already have, using the pattern framework.

The plan: take any system prompt you've written, split it into the seven patterns, identify what's missing and what's dead weight, and reassemble a clean version. Then test that the refactored version performs at least as well as the original.

You are a helpful assistant that helps summarize documents.
Please try to be concise. Return bullet points if possible. If
the user gives you something weird, try to do your best.

[Identity]    You are a helpful assistant that helps summarize documents.
[Constraint?] Please try to be concise.
[Format?]     Return bullet points if possible.
[Escape?]     If the user gives you something weird, try to do your best.

Identity:        weak (generic "helpful assistant")
Capability:      missing
Constraints:     missing (hints don't count)
Format:          weak (optional)
Few-shot:        missing
Chain-of-thought: N/A
Escape hatch:    missing (abdication doesn't count)

[Identity]
You are a document-summarizer agent.

[Capability]
You read a single text document and return exactly three bullet
points summarizing it.

[Constraints]
Rules:
- Always return exactly three bullets.
- Each bullet is one sentence under 20 words.
- Never include any text outside the bullets.

[Format]
- bullet 1
- bullet 2
- bullet 3

[Escape hatch]
If the input is not readable text, reply with:
"I couldn't read the input. Try a plain text document."

$ claude --agent old-summarizer "summarize /tmp/article.md"
$ claude --agent new-summarizer "summarize /tmp/article.md"

What you just did

You took an implicit-pattern prompt and made the patterns explicit. Same content area, clearer structure. The LLM now has clear signals for each behavior you want: it knows who it is, what it can do, what's required, what the output looks like, and what to do on edge cases.

This is the refactoring loop for every prompt you ever write. Label the patterns. Find what's missing. Fill the gaps. Ship.

Rookie has the three ways this refactoring goes wrong.

Three ways pattern-based refactoring goes sideways.

Failure 1. Pattern overload

You learned seven patterns. You use all seven in every prompt. Your six-line task description balloons to forty lines. The agent slows down, costs more, and doesn't behave better.

Root cause: treating patterns as a checklist instead of a toolkit.

Fix: start with the three minimums (identity, constraints, escape hatch). Add others only when you can articulate the specific reason. "Because I learned it in Module 005" is not a reason.

Failure 2. Pattern cargo-culting

You copy a pattern shape from somewhere without adapting it to your task. You end up with a chain-of-thought scaffold on a simple classification task, or a five-example few-shot block for a task where one example would do.

Root cause: mistaking the pattern name for the pattern's purpose.

Fix: before adding a pattern, write one sentence explaining why this task needs it. "This task needs chain-of-thought because the classification depends on a multi-step decision." If you can't write that sentence, skip the pattern.

Failure 3. Skipping patterns that matter

You refactor a prompt, stack four or five patterns, and ship it. In production, it breaks on edge cases, and you realize you never wrote an escape hatch.

Root cause: patterns that feel optional actually aren't.

Fix: escape hatch is never optional. Every prompt has one. Even a one-line one. "If the input doesn't make sense, say so and ask for clarification." That's an escape hatch. No prompt ships without it.

The audit question

After you refactor, ask: "what happens on an input I haven't thought of?"

If the answer is "I don't know," the prompt isn't done. Come back to the escape hatch. Strengthen it. Ship when you can predict the behavior on weird inputs, not just the happy path.

Manager takes the team view.

A pattern library is how teams write prompts that don't all look different.

The library shape

Your team's prompt library is a folder of reference examples. One file per pattern, with:

• A one-paragraph description of what the pattern does.
• Two or three real examples pulled from your team's actual prompts.
• Notes on when to use it and when to skip it.
• A list of production prompts that use this pattern (updated when prompts change).

This doesn't need to be fancy. A markdown file per pattern in a shared repo is enough.

patterns/
  01-identity.md
  02-capability.md
  03-constraints.md
  04-format.md
  05-few-shot.md
  06-chain-of-thought.md
  07-escape-hatch.md
  README.md         (index)

Pattern reviews

When someone on your team proposes a new pattern, or a significant variation of an existing one, review it before adopting.

Three questions:

1. What task does this pattern help with?
2. What's the failure mode if you don't use it?
3. What existing pattern does it overlap with?

Pattern proliferation is the enemy. If a new pattern is 80 percent overlap with an existing one, merge them. If it's genuinely new, document when to use which.

The standard stack

Most teams converge on a house style: a standard pattern stack that every new agent starts from. It looks like this:

[Identity - one line]
[Capability - two to three lines]
[Constraints - three to five rules]
[Format - schema]
[Escape hatch - one paragraph]

Five patterns, always. Few-shot and chain-of-thought are added only when needed. A new agent author starts from this template and fills in each block.

This sounds rigid but it's the opposite. A standard stack means less time arguing about prompt structure and more time on what the prompt actually says. The structure is solved; the content is where the thinking happens.

Enforcing patterns without enforcing uniformity

Patterns give you shared vocabulary. They don't make every prompt sound the same. A well-patterned identity for a support-triage agent and a well-patterned identity for a creative-writing agent will be completely different in tone. Same pattern, different content.

What matters for team consistency: that every prompt has an identity, has constraints, has an escape hatch. What doesn't matter: that every identity line sounds the same. Let authors write in their own voice; hold the structure constant.

Chief handles the governance layer.

Prompt patterns are an organizational asset. Treat them like one.

Patterns are institutional knowledge

Every time an engineer on your team writes a prompt, they're encoding a lesson learned. "Always include an escape hatch" is a lesson. "Put identity first" is a lesson. Without a pattern library, every new engineer re-learns these the hard way.

A documented pattern library:

• Reduces ramp-up time for new hires working on agents.
• Reduces the variance in prompt quality across the team.
• Captures the "why" behind structural decisions in a way that survives turnover.

It's not glamorous. It's cheap to build. It compounds.

Cost of un-patterned prompts

Un-patterned prompts have three hidden costs:

1. Higher token count. Un-patterned prompts are usually longer than they need to be, because authors repeat themselves without realizing it.
2. Lower reliability. Without explicit constraints and escape hatches, the agent drifts more. More drift means more retries, more user confusion, more support tickets.
3. Harder to debug. When the agent misbehaves, un-patterned prompts are harder to read and harder to modify. The team spends longer on each fix.

At small scale these costs are invisible. At scale they're the reason your AI budget is 30 percent higher than it needs to be.

The quarterly review

Once a quarter, review the pattern library with the team. Three questions:

• Which patterns do we use most?
• Which patterns have gone unused?
• What patterns do we keep reinventing?

Used patterns earn their place. Unused ones should be pruned or reconsidered. Reinvented patterns are the ones to document formally before they accumulate as tribal knowledge.

Governance lite

You don't need a prompt-review-committee to ship an agent. You do need:

• A documented house pattern stack (the standard five).
• A review checklist for new prompts (does it have identity, constraints, format, escape hatch).
• A changelog when patterns change, so people downstream know to update.

This is operational hygiene. It's also the difference between a team that ships reliable agents and a team that ships agents that occasionally do weird things.

The executive frame

Prompts are how your company's AI agents behave. A pattern library is how that behavior stays consistent as people, priorities, and models change. Two minutes of thought about this at the leadership level prevents a year of regrets at the IC level.

Founder wraps it.

Your personal pattern notebook is one of the highest-leverage assets you'll build.

Start the notebook today

One file. ~/prompts/patterns.md, or whatever you prefer. Every time you write a prompt that works, copy the key shape into the notebook with a one-line note about what made it work.

patterns.md
=============

## Identity
Pattern: "You are a [role] for [product]."
Worked well for: triage, briefing, classification.
Note: keep it one sentence.

## Constraints
Pattern: "Rules: - Always X. - Never Y. - Only Z."
Worked well for: every structured output task.
Note: three to five rules. More than five, you're over-specifying.

## Escape hatch
Pattern: "If [input doesn't fit], reply with [specific message]."
Worked well for: every agent I've ever built.
Note: NEVER skip this.

Three patterns is enough to start. Add to the notebook every time you discover something new.

The rewrite habit

Once a month, pick your oldest agent prompt. Read it. Rewrite it using your current pattern vocabulary. Compare side by side.

Two things will happen:

• The rewrite will be shorter and clearer.
• You'll notice patterns you now reach for that you didn't know existed when you wrote the original.

This is how you see your own growth. The old prompt is a snapshot of how you used to think. The rewrite is a snapshot of now. The delta is compounding skill.

Share the notebook

Your patterns notebook is a portfolio piece. When someone asks "how do you write good prompts?" the answer is not a blog post. It's your notebook.

If you're a solo operator, share it with other builders you respect. Trade notes. Their patterns are your patterns now. This is how the craft spreads.

Resist the pattern-of-the-week

Every month there's a new prompt-engineering technique on social media. Most of them are reframings of the seven patterns in this module. A few are genuinely new.

Test before adopting. Write a prompt with the new technique. Write one without. Compare on your real tasks. If the new technique helps, add it to your notebook. If it doesn't, move on.

The notebook gets stronger because you tested, not because you read.