Chapter 2: Prompt design: Structural elements

Introduction

The introduction explains how separating a prompt into structural elements clarifies each part’s role and makes prompts easier to reuse and diagnose.

• Roles of structural elements: Describe what instructions, constraints, context, input parameters, output format, and delimiters each contribute to a prompt.
  Why it matters: These roles let you identify which part of a prompt to change for a particular need.
• Value of separated prompt concerns: Explain why a single undifferentiated prompt is harder to diagnose and how separating its concerns helps.
  Why it matters: Clear separation gives you a more useful starting point when a prompt’s output goes wrong.

Key terms: instructions, constraints, context, input parameters, output format, delimiters, structural elements, separates concerns

2.1 Overview of structural elements

Introduces six prompt elements and shows how their distinct roles combine into a structured interface for more reliable model behavior.

• Roles of six structural elements: Describe the distinct roles of instructions, constraints, context, input parameters, output format, and delimiters in a prompt.
  Why it matters: Distinguishing these roles helps you choose what each part of a prompt needs to accomplish.
• Unified prompt interface: Explain why the six elements are presented together in one annotated prompt template.
  Why it matters: The template shows how separate prompt decisions work together rather than as isolated tricks.

Key terms: instructions, constraints, context, input parameters, output format, delimiters, unified template, structured interface, clarity, control

2.2 Instructions

This section explains what instructions do in a prompt and how to write them so the task is clear.

• Role of prompt instructions: Explain that instructions tell the model what task to perform and that clear instructions make outputs more consistent with that task. Distinguish instruction logic from background, input data, and output-format requirements.
  Why it matters: Separating the task from other prompt details makes it easier to diagnose and revise a prompt.
• Clear instruction writing: Describe how to make an instruction's action and scope clear: use one primary action, specify a relevant audience or technical context, state task boundaries, and order directives for multistep outputs.
  Why it matters: These choices help the model follow the intended task without guessing its scope or sequence.

Key terms: instructions, structural element, instruction logic, primary action, audience, technical context, task boundary, ordered directives

2.2.1 Practical example 1: Explaining HTTP 429 errors

A worked HTTP 429 example shows how a specific instruction guides a response without further direction.

• Specific instruction and response alignment: Explain how the HTTP 429 instruction specifies its audience, language, and content, and how the example response follows those directions.
  Why it matters: Specifying who a response is for, how it should sound, and what it should cover makes the requested output clearer.

Key terms: instruction, audience, register

2.2.2 Practical example 2: Generating code review feedback

A code review example shows how an instruction can focus feedback on particular concerns and adapt it to its intended reader.

• Scoped audience-aware review instructions: Explain how the example instruction sets the authentication-service domain, limits the review to correctness and security, and identifies a midlevel backend engineer as the audience. Describe how the resulting feedback gives specific issues and improvements while explaining unfamiliar security risks concretely.
  Why it matters: A well-targeted review prompt helps produce feedback that addresses the right risks in terms its reader can use.
• Instructions versus constraints: Distinguish an instruction about what the model should do from a constraint about what its output must not violate.
  Why it matters: Keeping the task separate from output boundaries makes each easier to state clearly.

Key terms: instruction, domain, correctness, security, audience, constraints

2.3 Constraints

This section defines constraints as testable restrictions on model output, distinguishes them from instructions and output format, and explains how to use them without treating them as guarantees.

• Constraints as distinct restrictions: Distinguish constraints from instructions and output format, and explain that constraints can restrict either the output itself or the scope of the task.
  Why it matters: This distinction helps you identify what a prompt is asking the model to do versus what its answer must not violate.
• Testable constraint wording: Explain what makes a constraint testable and contrast a specific example with a vague request.
  Why it matters: A checkable condition makes it possible to tell whether an output met the stated restriction.
• Relevant and consistent constraints: Describe how to choose constraints that serve the task without conflicting with the main instruction or unnecessarily restricting the response.
  Why it matters: Relevant, compatible limits guide the answer without making the task needlessly restrictive.
• Soft limits on compliance: Explain why a constraint cannot guarantee that a model’s output will satisfy it.
  Why it matters: Even a well-written constraint does not remove the need to check the resulting output.

Key terms: constraints, instructions, output format, task scope, testable, measurable, unambiguous, length constraint, task objective, main instruction

2.3.1 Practical example: Writing secure logging guidelines

A secure-logging example shows how instructions define a prompt’s task while specific constraints make its output requirements checkable.

• Instructions and verifiable constraints: Explain how the example separates the task of writing secure logging guidelines from constraints on the response, and identify how those constraints can be checked.
  Why it matters: Separating the task from checkable requirements makes it easier to evaluate whether a response meets the prompt.

Key terms: Instructions, Constraints, directive layer, correlation ID

2.4 Context

This section defines prompt context as task-specific background and shows a simple way to separate it from instructions.

• Purpose of prompt context: Explain that context is task-specific background written into the prompt to help the model interpret and follow instructions, and distinguish it from the model’s context window.
  Why it matters: Relevant background helps the model understand what the instruction is asking for.
• Explicit context and instruction structure: Describe the example pattern of placing a labeled context block before a separate instruction block, with background about the audience and situation preceding the requested ADR summary.
  Why it matters: Separating the background from the request makes each part of the prompt’s purpose clear.

Key terms: context, context window, task-specific background information, Additional Context, Instructions, ADR summary

2.4.1 Practical example 1: Generating an architecture decision record summary

This example shows how system context and an ADR-specific instruction produce a concise summary that preserves the reasons for an architecture decision.

• Contextualized ADR summary: Explain how the billing platform’s peak-invoicing failures and the ADR instruction shape the generated summary. Describe how the result stays concise while covering the decision, its tradeoffs, and its expected operational effect.
  Why it matters: Relevant context helps a short decision summary explain why the choice fits this particular system.

Key terms: Additional Context, ADR summary, decision context, tradeoffs, expected operational effect

2.4.2 Practical example 2: Generating an incident handoff conversation

A payment-outage handoff example shows how incident context and a concise instruction produce a short, operationally clear dialogue.

• Context for an incident handoff: Explain how the prompt uses context to establish the participants, their roles, the incident, and their communication styles before asking for a brief handoff dialogue.
  Why it matters: The distinction helps you supply incident-specific background without losing a clear request for the handoff.
• Variable context and stable instructions: Distinguish the variable incident details from the stable instruction logic in the example, without assuming any particular input-parameter mechanism.
  Why it matters: Separating changeable background from the task makes it easier to see what the handoff request consistently requires.

2.5 Input parameters

This section explains how input parameters turn a prompt template into a complete prompt before it is sent to a language model.

• Input parameter substitution: Explain that input parameters are placeholders in a prompt template that are filled with specific values, manually or programmatically, before the completed prompt is sent to the language model.
  Why it matters: It distinguishes the reusable template from the complete prompt the model actually receives.

Key terms: input parameters, prompt template, placeholders, runtime variable injection, fully resolved prompt

2.5.1 Practical example 1: Analyzing error logs

A worked error-log example shows how filling input parameters turns a reusable prompt template into an incident-specific prompt.

• Incident-specific prompt parameters: Explain how the error-log template stays reusable while accepting details from different incidents. Describe how filling its service, environment, and error-log placeholders produces a complete prompt for the model.
  Why it matters: You can reuse the same analysis request without rewriting it for every service failure.

Key terms: prompt template, input parameters, {service_name}, {environment}, {error_log}

2.5.2 Practical example 2: Generating release notes

A release-notes example shows how filling a reusable prompt template with release-specific inputs produces a concrete prompt, then gives practical rules for choosing and formatting input parameters.

• Release-specific template inputs: Explain how the release-notes template uses placeholders for the product, version, features, bug fixes, and breaking changes, and how filling them creates a prompt for a specific release.
  Why it matters: You can keep the release-notes instructions consistent while changing the information supplied for each release.
• Input parameter design practices: Describe the section’s rules for selecting and naming input parameters, keeping their syntax consistent, and defining an output format after parameterization.
  Why it matters: Clear, consistent variables make a template easier to reuse, while a defined output format makes its responses more predictable.

Key terms: prompt template, input parameters, template variables, release-specific context, input variables, input format, f-strings, Jinja2, output format

2.6 Output format

This section explains why every prompt needs an output format and how specifying it makes responses predictable.

• Required output format: Explain that output format is a required structural element that specifies the form an answer must take, and why defining it up front helps.
  Why it matters: Choosing the answer’s form up front helps you get responses you can use consistently.

Key terms: output format, structural element

2.6.1 Practical example 1: Generating a deployment checklist

A payment-service deployment checklist example shows how explicit output-format instructions make a response consistent and suitable for automatic processing.

• Structured deployment checklist format: Explain how the example prompt specifies a deployment checklist’s structure: numbered action items with prerequisites and verification steps, organized into three ordered sections.
  Why it matters: A predictable checklist structure makes the response easier to use in an automated workflow.

Key terms: output format, numbered list, Predeployment checks, Deployment steps, Postdeployment verification

2.6.2 Practical example 2: Generating an API endpoint summary

This example specifies a consistent key-value format for an API endpoint summary and explains why that format is useful.

• API summary output format: Describe how the prompt specifies an API endpoint summary as key-value pairs with fields in a fixed order, and explain why that format is useful for API documentation.
  Why it matters: A predictable structure makes endpoint summaries easier to reuse in documentation workflows.

Key terms: key-value pairs, Output Format, Endpoint, Method, Authentication, Request Body

2.7 Delimiters

This section explains how delimiters separate contextual content from instructions and recommends triple-backtick code fences for that purpose.

• Delimiters and context boundaries: Explain that delimiters mark the boundaries of context blocks so the model can distinguish contextual content from instructions, especially when input parameter values arrive at runtime.
  Why it matters: Clear boundaries help keep supplied context distinct from the prompt’s instructions.
• Recommended delimiter format: State that Markdown-style triple-backtick code fences are recommended for delimiting contextual content, and explain the stated reason for that recommendation.
  Why it matters: The recommendation gives you a conventional way to mark contextual content.

Key terms: delimiters, context blocks, input parameters, Markdown-style triple-backtick code fences, de facto standard

2.7.1 Practical example 1: Summarizing an incident report

The section uses an incident-report summary to show how delimiters separate source material from instructions, then explains how to choose and test delimiters.

• Incident report instruction boundary: Explain how triple backticks mark the incident report as content to summarize rather than instructions to follow, while the separate instruction specifies the summary’s focus and tone.
  Why it matters: A clear boundary helps the model use the report as evidence for the requested summary, not as a source of new commands.
• Delimiter selection and verification: Describe when triple backticks may be a poor delimiter and how to select and evaluate an alternative for reliable instruction–context separation.
  Why it matters: A delimiter that clashes with the input can undermine the separation the prompt relies on.

Key terms: triple backticks, delimiter, Additional Context, Instructions, alternative delimiters, instruction-context separation, evaluations

2.7.2 Practical example 2: Answering questions from a runbook

This example shows how an XML tag separates a runbook containing shell commands from a question that must be answered using the runbook.

• XML runbook boundaries: Explain why XML tags are useful delimiters when a runbook contains backticks, and how the example separates the runbook from the question and instruction while grounding the answer in a cited step.
  Why it matters: A clear boundary helps keep the source material distinct from the request to answer from it.

Key terms: XML tags, <runbook> tag, backticks, runbook

2.7.3 Defensive prompting tip

This section explains how to delimit embedded text to reduce instruction-mixing risk, while emphasizing that delimiters alone are not enough.

• Defensive boundaries for embedded text: Explain why external text should be placed in a clearly delimited context block and why delimiters alone do not make it safe to handle.
  Why it matters: External text can contain instructions that should remain data rather than direct the assistant.
• Clear delimiter placement: Describe the placement guidelines for making boundaries between prompt parts explicit.
  Why it matters: Clear, consistent boundaries make it easier to distinguish embedded content from the prompt's instructions.

Key terms: delimited context block, instruction-mixing risk, instruction boundaries, input hygiene, delimiters, context, instructions, input variables

2.8 Combining structural elements

This section gives a rule for combining prompt elements according to the task, including when to use input parameters.

• Required and optional prompt elements: Explain which structural elements to include in every prompt and how to decide whether to add the others.
  Why it matters: This keeps prompt structure tied to the task rather than treating every element as mandatory.
• When input parameters help: Distinguish static task inputs from values that change across runs when deciding whether to use input parameters.
  Why it matters: Input parameters are useful when one prompt needs to work with different values on different runs.

Key terms: instructions, output format, constraints, context, input parameters, delimiters, static, reusable prompt template

2.8.1 Practical example 1: Generating incident status updates

The example combines structural prompt elements to turn checkout incident notes into a consistent, stakeholder-facing status update.

• Incident prompt structure: Explain how context, delimited incident notes, instructions, constraints, and a fixed output format work together in this example. State why input parameters are not used in this run.
  Why it matters: Separating these jobs makes an incident update easier to control and scan.
• Evidence bound status reporting: Describe how the example reports the incident’s impact, mitigation, and next checkpoint while keeping a suspected cause distinct from a confirmed root cause.
  Why it matters: Stakeholders need the current state without a suspected explanation being presented as fact.

Key terms: Additional Context, Input parameters, Delimiters, Instructions, Constraints, Output Format, incident notes, Root Cause (Known/Unknown), Mitigation in Progress, Next Update ETA

2.8.2 Practical example 2: Generating a deployment GO/NO-GO brief

A worked deployment example shows how to combine prompt elements to produce an evidence-based, actionable GO/NO-GO brief.

• Deployment brief prompt composition: Explain how the example combines context, delimiters, instructions, constraints, and output format, and why it does not use input parameters.
  Why it matters: It shows how to choose prompt elements for the decision at hand rather than include every element by default.
• Evidence based rollback recommendation: Describe how the example supports its NO-GO recommendation with deployment signals and runbook information, and connects the decision to an immediate rollback action and risks to monitor.
  Why it matters: A release decision is more useful when its evidence and next action are visible together.

Key terms: Context, Delimiters, Instructions, Constraints, Output Format, Input parameters, GO or NO-GO, deployment signals, runbook excerpt, rollback threshold

2.8.3 Hands-on practice

This hands-on section asks readers to design prompts for software delivery tasks using structural elements deliberately, then connects that approach to systematic prompt engineering.

• Task-specific structural prompt design: Apply the chapter’s structural elements to a software delivery task: include instructions and an output format, then add context, input parameters, constraints, or delimiters only when relevant. Describe how the requested output and any constraints would be made explicit.
  Why it matters: A prompt tailored to its task makes the requested deliverable and its requirements clear.
• Systematic value of structural elements: Explain why the section presents structural elements as a foundation for prompt design in software delivery.
  Why it matters: This is the reason to design prompts deliberately instead of repeatedly guessing at wording.

Key terms: instructions, output format, context, input parameters, constraints, delimiters, structural elements, systematic engineering practice, reusable, testable

2.9 Summary

This section summarizes what each structural prompt element does and how to choose elements when assembling a prompt.