Chapter 4: Patterns

Introduction

The introduction positions prompt patterns as repeatable strategies that extend prompt structure and wording to address common interaction problems.

• Purpose of prompt patterns: Explain how prompt patterns differ from the structural and linguistic elements covered earlier: those elements help form a prompt, while patterns provide repeatable strategies for common prompting problems.
  Why it matters: This distinction helps you choose a prompting strategy rather than focus only on how a prompt is structured or worded.

Key terms: prompt patterns, structural elements, linguistic elements

4.1 Understanding prompt patterns

This section defines prompt patterns as reusable task strategies and introduces three categories based on what those strategies do.

• Reusable prompt strategies: Explain how prompt patterns differ from formatting choices and why they transfer across tasks.
  Why it matters: This distinction helps you reuse an approach instead of treating every prompt as a new formatting problem.
• Three pattern categories: Distinguish structural, contextual, and transformational patterns by the purpose assigned to each in this section.
  Why it matters: The categories give you a way to choose a pattern based on the kind of help the task needs.

Key terms: prompt patterns, structural and linguistic elements, transferability, structural patterns, contextual patterns, transformational patterns

4.2 Role assignment pattern

This section introduces role assignment as a low-overhead prompt pattern that shapes the model’s approach to a task and is especially useful when expertise, audience fit, or professional credibility matters.

• Role assignment and task approach: Explain that role assignment asks the model to adopt a persona, expertise, or voice before doing a task, shaping its approach and producing more domain-appropriate language and recommendations than a generic prompt.
  Why it matters: An assigned role can make an answer better suited to the domain rather than merely changing its tone.
• Role assignment use cases: Describe why the section recommends using role assignment in almost every prompt, and name the situations where it matters most: seeking specialized knowledge outside your expertise, targeting an audience, or conveying professional credibility.
  Why it matters: These needs help you recognize when a generic prompt is especially likely to fall short.

Key terms: role assignment pattern, persona, expertise, voice, specialized knowledge, specific audience targeting, professional credibility

4.2.1 Practical example: Pull request description generation

This section compares two PR descriptions for the same refactor to show how a specific, credible role assignment can make the output more useful to reviewers.

• Reviewer-focused PR description: Explain how assigning a code-review role changed the PR description for the UserService refactor compared with the standard prompt.
  Why it matters: A reviewer-focused description can help people review a complex change more quickly and deliberately.
• Credible role specification: Describe how to choose and specify a role for this kind of technical writing task, and why those details matter.
  Why it matters: A credible, task-matched role helps steer the answer toward the decisions its intended reader needs.

Key terms: role assignment, PR description, How to Review, service boundaries, profession or expertise, contextual background, measurable outcomes, domain-aware judgment

4.3 Delimiter pattern

The section presents delimiters as a repeatable way to organize complex prompt templates, explains how to mark their boundaries, and gives a check for delimiter conflicts.

• Delimiter pattern purpose: Explain how the delimiter pattern separates variable content from instructions and why that helps with reusable or complex prompts.
  Why it matters: Clear boundaries make a prompt template easier for others to inspect and maintain.
• Markdown prompt boundaries: Describe the distinct jobs of headings, separators, and fenced code blocks in a Markdown-based prompt.
  Why it matters: Using each boundary for its intended job makes the template easier to read and inspect.
• Delimiter use and conflicts: Explain when clear delimiters are especially useful and what to check if a prompt template gives inconsistent results.
  Why it matters: A boundary that also appears in the input can undermine the clarity the pattern is meant to provide.

Key terms: delimiter pattern, variable content, instructions, prompt template, headings, separators, fenced code blocks, user-generated content, delimiter types, multiple data sources

4.3.1 Practical example: Multisource bug analysis

This section uses a multisource bug-analysis prompt to show how delimiters separate inputs and make a reusable template easier to maintain.

• Multisource input boundaries: Explain how the delimited bug-analysis prompt separates the error log, recent change summary, and relevant code while keeping the root-cause instruction distinct from those inputs.
  Why it matters: Clear boundaries help a reader of the prompt tell source material apart from the task instruction.
• Template maintenance benefits: Justify why the delimited version is easier to populate, update, and debug than the undelimited version.
  Why it matters: The same boundaries that make the prompt readable also make a reusable template easier to change and troubleshoot.

Key terms: delimiter pattern, headings, separators, fenced blocks, prompt templates, input sources, variables, delimiter discipline

4.4 Template pattern

This section explains how the template pattern makes repeated outputs predictable by defining their structure, and when that consistency is useful.

• Template pattern output structure: Explain how the template pattern makes outputs consistent and distinguish it from the delimiter pattern.
  Why it matters: Defining the output shape helps repeated workflows produce predictable results.
• Template pattern use cases: Describe when to apply the template pattern and when to leave room for a more flexible output.
  Why it matters: A fixed format is useful when consistency matters, but can be restrictive when it does not.

Key terms: template pattern, fixed schema, output structure, delimiter pattern, consistent formatting, automated systems, one-off creative tasks

4.4.1 Practical example: Incident postmortem summaries

This example shows how an explicit output template makes incident postmortem summaries consistent and easier to use.

• Consistent postmortem output structure: Explain how the template changes the incident summary compared with an instruction to summarize alone. Describe why fixed fields in a fixed order make repeated summaries easier to compare, reuse, and check for omissions.
  Why it matters: A predictable structure makes recurring engineering summaries easier to review and use.
• Practical template field design: Describe the fields used in the postmortem template and the guidance for making a template specific without making it too rigid.
  Why it matters: Concrete, limited fields give the model clear slots to fill without forcing every incident into overly rigid wording.

Key terms: template pattern, output contract, fields, Incident, Effect, Root cause, Resolution, Action item, concrete placeholders

4.5 Repetition pattern

This section explains how repeating a full prompt can improve accuracy and why the pattern is easy to add to an existing workflow.

• Repeated prompt accuracy: Explain that repeating the full prompt lets the model read it twice before responding, giving it another chance to pick up important context near the beginning. Describe the reported results with their reasoning-disabled qualification.
  Why it matters: It gives you a simple way to help the model notice important context it might otherwise miss.
• Input-only workflow change: Explain why the repetition pattern can be added to an existing workflow without changing its expected output format.
  Why it matters: You can try the pattern without redesigning the format your workflow expects.

Key terms: repetition pattern, full prompt, second pass, input, output format, existing workflows

4.5.1 When to use the repetition pattern

This section explains when repetition is worth using and when its token and latency costs make it a poor choice.

• Repetition pattern selection: Explain when to use repetition for a prompt and when to skip it, based on the need for first-response accuracy, the location of important context, reasoning settings, and context-window limits.
  Why it matters: These conditions help you decide whether repetition is likely to be worth adding to a prompt.
• Repetition cost tradeoff: Describe how repetition affects input tokens and latency, and why that tradeoff may be acceptable for one high-stakes response but not for a high-volume workflow.
  Why it matters: The accuracy benefit has to justify the extra input tokens and possible delay.

Key terms: repetition pattern, nonreasoning configurations, context window, input tokens, output tokens, latency, token efficiency

4.5.2 Practical example: Selecting a logging approach

This example shows how repeating an identical logging-selection prompt can produce a more grounded comparison, while weighing the extra token cost.

• Repetition and answer grounding: Explain how repeating the same prompt changed the logging answer: the baseline chose asynchronous logging correctly, while the repeated version compared all four options against request-path overhead and tied its recommendation to the supplied descriptions.
  Why it matters: A correct short answer can still benefit from a fuller comparison grounded in the provided options.
• Logging request-path tradeoffs: Explain why asynchronous logging has the lowest request-path overhead in this example and how the other approaches compare. Describe the main risks that remain with asynchronous batching.
  Why it matters: The logging comparison makes the repeated answer's grounding concrete rather than merely asserting that it is better.
• Faithful repetition and token cost: Describe how to repeat the prompt faithfully and when the additional tokens may not be worthwhile.
  Why it matters: Repetition is useful only if its potential grounding benefit justifies the extra prompt length.

Key terms: repetition pattern, grounded explanation, request-path overhead, asynchronous logging, critical path, enqueue operation, batching, backpressure, repeated prompt, token efficiency

4.6 Self-reflection pattern

Introduces self-reflection as an immediate critique of a model’s output and explains when the extra step is worthwhile.

• Immediate output critique: Explain that the self-reflection pattern asks a model to critique its own output immediately after generating it, to expose gaps and assumptions. Describe how it can be paired with refinement to evaluate and then improve the output.
  Why it matters: Critiquing a draft can reveal problems before it is improved or used.
• Selective use of self-reflection: Distinguish tasks where the quality benefit justifies self-reflection from tasks where its extra step is not worthwhile.
  Why it matters: The added critique is most useful when output quality warrants the extra step.

Key terms: self-reflection pattern, refinement, evaluation-then-improvement workflow, complex analysis, strategic recommendations, high-stakes outputs, simple factual queries, urgent work

4.6.1 Practical example: Technical onboarding plan

A technical onboarding example shows how self-reflection can preserve a plan’s strengths while revealing important omissions.

• Onboarding plan self-critique: Explain how asking the model to critique its onboarding plan identifies both strengths and overlooked requirements.
  Why it matters: A plausible technical plan can still miss what someone needs to work with the team and ship software.
• Internal and external gap finding: Distinguish the section’s description of self-reflection from inversion as ways to find omissions.
  Why it matters: The distinction clarifies what kind of challenge the onboarding example uses.

Key terms: self-reflection, onboarding plan, collaboration practices, delivery tooling, domain context, inversion, internal critique, external challenge

4.7 Inversion pattern

This section explains how inversion turns existing content into questions that reveal blind spots, when to use it, and how its questions can feed later refinement.

• Content to questions inversion: Explain how the inversion pattern changes the model’s task and why that change can reveal weaknesses in existing content.
  Why it matters: Questions from unfamiliar perspectives can expose gaps before you rely on the content.
• Role assignment distinction: Distinguish what role assignment controls from what inversion controls when the two patterns are combined.
  Why it matters: This distinction lets you choose a reviewer’s viewpoint without confusing it with the kind of output you want.
• Inversion use cases and limits: Describe when inversion is useful and when the section advises skipping it.
  Why it matters: Choosing inversion selectively keeps a questioning step where it is likely to improve the result.
• Questions before content refinement: Trace the basic sequence from inversion-generated questions to improved content.
  Why it matters: The questions are most useful when their answers feed back into the original content.

Key terms: inversion pattern, Content > Interrogation, blind spots, role assignment, inversion, domain perspective, external perspective, knowledge gaps, FAQ entries, multistep workflows

4.7.1 Practical example: Architecture proposal review

This example uses an inversion prompt to test a microservices migration proposal from stakeholder perspectives and expose risks the proposal leaves unanswered.

• Stakeholder perspective inversion prompt: Describe how the prompt substitutes an architecture proposal into a template and asks for challenging questions from security, site reliability, and junior developer perspectives.
  Why it matters: Distinct perspectives make it easier to find objections that a proposal’s author may overlook.
• Migration blind spots and risks: Explain what the generated questions reveal about the migration proposal and why those questions matter before approval.
  Why it matters: A promising migration goal is not enough for approval if important implementation and team risks remain unanswered.

Key terms: inversion, architecture proposal, external perspectives, blind spots, transactional integrity, cascading failures, cognitive load

4.8 Refinement pattern

This section explains refinement as the improvement step in a multistep workflow and when that step is useful.

• Refinement in the improvement loop: Explain how refinement acts on earlier evaluation: it addresses gaps identified through self-reflection or incorporates answers to questions raised through inversion into improved content.
  Why it matters: Refinement turns an evaluation into a better result, rather than simply repeating the original request.
• Conditions for useful refinement: State when to apply refinement and when to skip it based on the quality of the initial output and preceding feedback.
  Why it matters: A revision step needs a concrete reason to change the output.

Key terms: refinement pattern, self-reflection, inversion, evaluation-to-improvement loop, specific, actionable feedback, initial output, requirements

4.8.1 Practical example: API documentation improvement

This example shows how to turn a critique of sparse API documentation into a concise, more usable endpoint reference.

• Critique to refinement sequence: Trace how the example evaluates the original documentation, asks what developers need to use the endpoint correctly, and then uses that feedback to revise the documentation.
  Why it matters: Specific feedback gives a revision a clear target.
• Concise API reference improvements: Describe the gaps identified in the `POST /orders` description and the practical information added in the refined version, while noting its concise developer-focused tone.
  Why it matters: An endpoint description is more useful when developers can see what to send and what responses to expect.

Key terms: self-reflection, refinement pattern, feedback, request structure, bearer authentication, response behavior, developer-focused tone

4.9 Comment-driven generation

This section introduces comment-driven generation as a way to batch passage-specific feedback into targeted improvements to code or documentation.

• Anchored feedback in one pass: Explain how comment-driven generation handles multiple targeted changes by anchoring each comment to selected content and batching the feedback into one pass.
  Why it matters: You can give the model several precise edits without losing the relationship between them.
• Recommendation and refinement workflow: Trace the stated workflow from organizing comments through optional recommendations to implementing improvements.
  Why it matters: The workflow separates organizing feedback from deciding on and making the edits.
• Targeted review and comment specificity: Describe when to use comment-driven generation and why specific reviewer comments matter.
  Why it matters: Precise review comments make the resulting recommendations more actionable.

Key terms: comment-driven generation, anchored, selected passage, inversion pattern, refinement pattern, resolution recommendations, targeted improvements, structured review workflow, specific comments

4.9.1 Practical example: Technical Request for Comments review

This example shows how to turn comments tied to specific RFC passages into targeted revision guidance rather than generic feedback.

• Comment Anchored Revision Guidance: Explain how comment-driven generation uses each reviewer comment and its selected text to identify a specific gap and recommend a targeted revision.
  Why it matters: Anchoring advice to a passage makes review feedback actionable.
• Rate Limiting RFC Gaps: Describe the three gaps identified in the rate-limiting RFC and the kinds of additions recommended for each.
  Why it matters: The example shows what actionable revision guidance looks like for a technical proposal.

Key terms: comment-driven generation, selected text, targeted revision guidance, observable evidence, technical approach, implementation scope

4.9.2 Hands-on practice

This hands-on section asks readers to combine prompt patterns in practical workflows, compare the results with a baseline, and recognize how patterns can complement one another.

• Baseline and iteration workflow: Apply a repeatable practice workflow: start with a baseline prompt, record its first output, combine the specified patterns, and compare the results for quality, reliability, and effort.
  Why it matters: A recorded baseline gives you a way to judge whether combining patterns actually helped.
• Complementary pattern combinations: Explain how patterns can work independently or together, using the section’s examples of self-reflection identifying gaps for refinement to fix and inversion surfacing blind spots for actionable feedback.
  Why it matters: Choosing complementary patterns lets you use the findings from one step to guide the next.

Key terms: baseline prompt, first output, quality, reliability, effort, self-reflection, refinement, inversion, comment-driven generation, blind spots

4.10 Summary

The section summarizes how prompt patterns make outputs more consistent and help teams find and fix weaknesses before they cause costly revisions.