Chapter 5: Templates

Introduction

This introduction defines reusable prompt templates, explains how changing inputs fit into a stable framework, and emphasizes evaluation before use.

• Prompt template meaning: Distinguish a prompt template, which is a reusable framework for recurring tasks, from the chapter 4 template pattern, which enforces a fixed output structure. Describe how prompt templates combine structural elements, linguistic elements, and prompt patterns.
  Why it matters: The distinction keeps a reusable framework from being confused with one particular output-format pattern.
• Stable logic and changing inputs: Explain how dynamic input parameters let one stable prompt template serve different scenarios by replacing placeholders while preserving its core task logic.
  Why it matters: Separating stable logic from changing inputs is what makes the same template reusable.
• Evaluation before reuse: Justify testing a reusable prompt template across varied input combinations before real-world use to check response quality, consistency, and failure behavior.
  Why it matters: Testing varied inputs helps reveal unreliable responses before a template is reused in practice.

Key terms: prompt template, template pattern, structural elements, linguistic elements, prompt patterns, dynamic input parameters, input variables, placeholders, core logic, prompt evaluation

5.1 Prompt templates as reusable frameworks

Defines prompt templates as reusable prompts with stable core logic and runtime inputs, and recommends storing them outside source code.

• Reusable template core and inputs: Explain how a prompt template handles a recurring problem: runtime input parameters vary the case-specific details while core instructions, constraints, and output structure remain stable. Describe why that lets teams reuse the template and compare its outputs.
  Why it matters: This distinction helps you see what should stay fixed when a prompt is reused for a new case.
• External template file storage: State the section’s recommendation to store prompt templates in external template files rather than inline in source code.
  Why it matters: Keeping the template in its own file follows the section’s recommended way to organize reusable prompts.

Key terms: prompt template, input parameters, core template logic, external template files, Jinja2, Markdown

5.2 Practical example 1: Feature implementation plan generator

The section identifies the planning problems caused by loosely written tickets and inconsistent drafting, then introduces a prompt template as a way to produce consistent plans from changing ticket data.

• Consistent implementation planning: Explain why engineering teams need a consistent way to turn product tickets into implementation plans, and what a prompt template is intended to provide.
  Why it matters: This is the problem the feature implementation plan generator is meant to address.

Key terms: product tickets, implementation plans, prompt template, ticket data

5.2.1 Prompt template components

This section explains how structural elements, linguistic choices, and prompt patterns combine to make a reusable feature implementation planning template.

• Reusable planning template structure: Describe how the template organizes the planning task, feature-specific inputs, and required output so it can produce consistent plans for different requests.
  Why it matters: Separating fixed planning requirements from changing feature details makes plans more consistent across requests.
• Language choices for reliable plans: Explain how precision, directness, and brevity shape the implementation plans produced by the template.
  Why it matters: These wording choices help the same template produce useful plans without unnecessary prompt length.
• Role and template patterns: Explain what role assignment and the template pattern contribute to this planning prompt.
  Why it matters: The two patterns guide both the practical perspective of the plan and the consistency of its presentation.

Key terms: instructions, constraints, input parameters, output format, plan schema, precision, directness, brevity, role assignment, senior software engineer

5.2.2 Prompt template

This section presents a feature implementation plan prompt template that grounds a sprint-ready plan in supplied request details and specifies its output structure.

• Feature request grounding: Explain how the template uses feature request fields to keep an implementation plan within the supplied facts and constraints.
  Why it matters: Grounding the plan in the request helps prevent unsupported work from entering it.
• Implementation plan output structure: Describe the plan the template requests and the sections and length requirements it gives for the response.
  Why it matters: The specified format makes the requested plan easier for a team to follow and review.

Key terms: Feature Request, constraints, business goal, acceptance criteria, target release, Role Assignment, Implementation Steps, Risks, Scope, Delivery Checkpoint

5.2.3 Prompt with input parameters injected

An injected feature request demonstrates how a reusable template produces a structured implementation plan that respects the request’s constraints.

• Feature criteria into implementation: Trace how the API key rotation request becomes implementation work: nonbreaking data changes, expiry enforcement and reminders, followed by a migration that preserves existing keys.
  Why it matters: A useful generated plan has to translate the request into executable work without overriding its constraints.
• Template controls on the plan: Distinguish what role assignment, constraints, and output format each contribute to the generated plan, including its risks and release checkpoint.
  Why it matters: Separating content limits from presentation rules makes a template easier to reuse and maintain.

Key terms: acceptance criteria, nonbreaking data model extensions, migration, grace period, role assignment, constraints, output format, template pattern, output schema

5.3 Practical example 2: Legacy module refactor plan generator

The section explains why legacy-module refactor plans need to uncover missing constraints before turning answers into a plan.

• Legacy refactor planning risks: Explain why planning a legacy-module refactor from a single prompt is risky, and describe the example’s two-step approach: ask gap-finding questions with inversion, then use the answers in a refinement-based template to produce a safer plan.
  Why it matters: Missing constraints in a legacy refactor plan can lead to outages, regressions, or release delays.

Key terms: legacy modules, hidden coupling, data-contract assumptions, operational risk, inversion, refinement

5.3.1 Prompt template components

This section identifies the structural, linguistic, and pattern components of a two-stage prompt template for safer legacy-module refactor planning.

• Two-stage refactor planning flow: Explain why the template asks risk-discovery questions before producing a refactor plan, and how the answers inform safer sequencing and controls.
  Why it matters: Clarifying risks first helps keep dependencies and rollback needs from disappearing into a premature plan.
• Planning inputs and output boundaries: Describe how the template supplies module context and planning constraints, separates technical context from instructions, and formats the assessment and final plan.
  Why it matters: Clear inputs and distinct outputs make the planning decisions easier to ground and review.
• Focused language and role choices: Describe how the template's limits, commands, brevity, and assigned role support focused refactor planning.
  Why it matters: These choices steer the response toward concise, concrete planning rather than open-ended advice.

Key terms: risk-discovery questions, inversion pattern, refinement pattern, hidden dependencies, rollback requirements, legacy_module_context, refactor_goal, timeline, team_capacity, risk_tolerance

5.3.2 Prompt template

The section presents a legacy-refactor prompt template that asks for risk-revealing questions before a plan and leaves slots for the module context and planning parameters.

• Questions before the refactor plan: Explain that the template assigns a staff software engineer role and requires three short questions about hidden dependencies, migration risk, and rollback needs before proposing a refactor plan.
  Why it matters: The order keeps the prompt from jumping straight to a plan without first surfacing potential risks.
• Legacy refactor template inputs: Describe the template's placeholders for legacy module context, refactor goal, timeline, team capacity, and risk tolerance.
  Why it matters: These slots show what case-specific information the reusable prompt expects.

Key terms: Role Assignment, hidden dependencies, migration risk, rollback needs, Legacy Module Context, Refactor Parameters, refactor goal, timeline, team capacity, risk tolerance

5.3.3 Prompt with input parameters injected

A legacy-refactor example shows how questions about hidden risks feed a reusable refinement prompt and produce a plan with explicit rollout and rollback safeguards.

• Risk discovery before planning: Explain how the inversion step asks about downstream consumers, implicit service contracts, and rollback options before a refactor plan is proposed.
  Why it matters: A plan is safer when it accounts for contracts and rollback limits that were not obvious in the original request.
• Assessment answers in the template: Describe how the refinement prompt uses injected assessment answers alongside the refactor goal, timeline, team capacity, and risk tolerance to request a concise plan with rollout and rollback logic.
  Why it matters: Injecting the findings makes the template respond to this refactor’s actual risks rather than a generic legacy-module scenario.
• Risk informed refactor safeguards: Trace how the example plan responds to the discovered contracts and rollback gap through behavior-preserving tests, incremental changes, controlled rollout, and a checkpoint for rollback.
  Why it matters: The example makes the value of discovery visible in the specific safeguards chosen for the refactor.

Key terms: inversion step, downstream consumers, implicit service contracts, rollback mechanics, refinement prompt template, assessment answers, input parameters, refactor parameters, characterization and contract tests, existing interface

5.3.4 Hands-on practice

This hands-on section gives readers a workflow for building and comparing reusable prompt templates, then asks them to apply it to several engineering tasks.

• Template building and comparison workflow: Apply the section’s workflow: identify the structural and linguistic elements and prompt patterns in use, separate fixed template text from runtime inputs, record a baseline output, and compare it with an iterated template.
  Why it matters: A recorded baseline and explicit comparison make it easier to tell whether a reusable template improved the result.
• Template adaptation boundaries: Describe how to adapt one engineering prompt template to another engineering context while preserving its core logic, and how to check the result.
  Why it matters: This tests whether a template is reusable without redesigning the workflow it expresses.

Key terms: structural elements, linguistic elements, prompt patterns, input parameters, baseline prompt, structure compliance, core logic, role framing, constraints

5.4 Summary

This summary explains how stable prompt templates, dynamic inputs, combined design techniques, and multistep workflows support repeatable results.