Chapter 6: Prompt types

Introduction

The introduction explains why a prompt that combines enduring instructions with changing data can be split into system and user prompts.

• Stable instructions and variable input: Explain why repeatedly copying a monolithic prompt to change its data is awkward, and describe how chat models separate stable behavioral instructions from changing input.
  Why it matters: Separating what stays the same from what changes avoids treating every new request as a wholly new prompt.

Key terms: monolithic prompt, stable behavioral instructions, variable input data, system prompts, user prompts

6.1 Chat model architecture

This section contrasts isolated text-completion requests with chat APIs that send role-tagged messages to separate instructions from user input and support multiturn conversations.

• Completion and chat API structure: Explain how early completion APIs differ from modern chat APIs, and describe how role-tagged messages separate persistent instructions from changing user input while supporting multiturn context.
  Why it matters: The message structure is the foundation for designing prompts in a chat-based application.

Key terms: completion engines, chat APIs, structured message roles, system, user, assistant

6.1.1 Three message types

This section distinguishes system, user, and assistant messages and shows how their roles shape a multi-turn chat conversation.

• Three chat message roles: Distinguish system, user, and assistant messages by what each contains and who creates it. Explain that you design the system and user messages, while the model generates assistant messages.
  Why it matters: The distinction clarifies which parts of a chat you can design and which parts the model produces.
• Accumulating conversation context: Trace how the troubleshooting example uses a stable system message and accumulating user and assistant messages to narrow an API problem across two turns.
  Why it matters: This explains why a later response can become more specific while following the same standing instructions.

Key terms: system message, user message, assistant message, conversation history

6.1.2 What you design: System and user prompts

This section explains which chat prompts you design, where changing input belongs, and how that separation can support prompt caching.

• System and user prompt roles: Distinguish what belongs in system prompts versus user prompts and explain how each is sent to a chat model.
  Why it matters: The distinction helps you place stable behavior and each request’s content in the appropriate messages.
• Variable input placement: Explain where changing template inputs typically belong and how the section frames them.
  Why it matters: It gives you a practical default for separating reusable instructions from request-specific data.
• Authored assistant examples: Distinguish ordinary assistant messages from assistant messages a prompt designer crafts as examples.
  Why it matters: It clarifies why an assistant message might appear among messages you prepare for a chat request.
• Static prompts and caching: Explain why the section recommends keeping system prompts static when possible.
  Why it matters: Separating stable instructions from variable data can also reduce costs where the provider supports caching.

Key terms: system prompts, system messages, user prompts, user messages, input variables, system prompt, delimiters, {{incident_report}}, assistant messages, example exchanges

6.2 System prompts

This section explains how system prompts set consistent model behavior across interactions, in contrast to user prompts that change from one interaction to the next.

• System prompt role and stability: Explain that a system prompt sets the model’s consistent behavior by specifying its role, instructions, output format, and communication style, while user prompts vary by interaction.
  Why it matters: This distinction helps you decide which instructions should stay consistent across requests.

Key terms: system prompts, user prompts, role assignment, output format, communication style

6.2.1 Purpose and principles

This section explains how system prompts establish consistent behavior and why each should have one well-defined responsibility.

• System prompt behavior elements: Explain how instructions, constraints, static context, and output format contribute to consistent behavior in a system prompt.
  Why it matters: These elements give the assistant a stable basis for responding across requests.
• User supplied input parameters: Distinguish input parameters from the stable content of a system prompt.
  Why it matters: It separates request-specific input from the system prompt’s standing behavior.
• Single system prompt responsibility: Explain why a system prompt should have one well-defined purpose and identify when separate prompts may be needed.
  Why it matters: A clear responsibility makes the behavior a system prompt establishes easier to define.

Key terms: Instructions, Constraints, Context (static background), Output format, Input parameters, delimited form, single, well-defined purpose, single responsibility principle

6.2.2 Quick reference: Mapping chapter 2 elements to chat prompts

This section maps prompt elements to system and user messages, then qualifies system-prompt length and authority.

• Stable and changing prompt content: Explain how to divide prompt content between system and user prompts: put stable instructions, constraints, output format, and background context in the system prompt, and changing requests, values, and context in the user prompt. Describe delimiters as a boundary technique used inside prompts rather than a separate content category.
  Why it matters: This split helps keep reusable behavior separate from the input that changes with each request.
• System prompt length guidance: State the section’s approximate system-prompt length guidance and explain what to check when a prompt is much longer.
  Why it matters: Length is a diagnostic cue, not an automatic reason to reject a prompt.
• System prompt security limits: Explain why a system prompt’s behavioral guidance should not be treated as a security boundary.
  Why it matters: A system instruction alone cannot guarantee that an assistant will resist hostile input.

Key terms: system prompt, user prompt, static context, variable context, input parameters, delimiters, system prompt length, tokens, behavioral guidelines, strong defaults

6.2.3 Practical example: Linear issue assistant

The Linear issue assistant example shows how separating shared issue-writing standards from each engineer’s task request produces consistent issues without repeating the standards in every prompt.

• Shared Standards and Task Input: Explain how the example splits a complete issue-writing prompt into a system prompt for reusable behavior and output structure and a user prompt for the changing task description. Describe why this is preferable to making every engineer repeat the full prompt.
  Why it matters: This split lets a team maintain one set of issue standards while engineers submit different tasks.
• Issue Quality and Uncertainty: Describe how the resulting issue follows the team’s title, description, and language standards while treating the suspected JavaScript error as a possibility rather than an established root cause.
  Why it matters: A consistent issue should be actionable without mistaking an unverified diagnosis for a confirmed cause.

Key terms: system prompt, user prompt, monolithic approach, output structure, acceptance criteria, output format, root cause, constraints

6.3 User prompts

This section distinguishes the changing input in user prompts from the stable behavior set by system prompts.

• User prompt role and variability: Explain that user prompts carry the input an LLM application processes—requests for help, data to analyze, or both—and change with each interaction, unlike system prompts that establish behavior and remain constant.
  Why it matters: This distinction helps you decide which information belongs in each prompt.

Key terms: user prompts, system prompts, user input

6.3.1 Types and templates

This section distinguishes three user-prompt types by what the user supplies and explains why data blocks may be delimited.

• Three user-prompt types: Distinguish query-based, context-based, and query-plus-context user prompts by what the user supplies and the task defined by the system prompt.
  Why it matters: The kind of user prompt follows from what the assistant is meant to do.
• Delimited context boundaries: Explain what delimiters do around variable data blocks in a context-based user prompt and what they do not do.
  Why it matters: Clear data boundaries help structure a prompt without creating a false sense of security.

Key terms: query-based user prompts, context-based user prompts, query + context user prompts, system prompt, delimiters, variable blocks, prompt hygiene, adversarial inputs

6.3.2 Practical example: Harvest daily report assistant

A Harvest daily report example shows how a fixed system prompt and a reusable user prompt template turn changing work evidence into consistent reports.

• System and user prompt roles: Explain that the system prompt sets the reporting task, structure, and constraints, while the user prompt supplies evidence for a particular day.
  Why it matters: This separation lets the same reporting instructions work with new evidence each day.
• Reusable daily input template: Describe how the user prompt template organizes changing daily material into named fields while leaving the report format fixed.
  Why it matters: Named inputs make varied daily source material usable without redesigning the report.
• Evidence grounded report output: Trace how the example turns supplied work items into a categorized summary and a concise two-paragraph daily report.
  Why it matters: The example shows how scattered engineering records become a usable report without losing their connection to the source material.

Key terms: system prompt, user prompt, day-specific evidence, user prompt template, input parameters, values injected, Work Context, Summary of Work, Daily Report, Output Format

6.4 Prompt decomposition framework

Introduces the task of splitting complete prompts and templates for chat model APIs, without yet explaining how to do it.

6.4.1 The core question

This section gives a single question for splitting a prompt into system and user components.

• System versus user content: Apply the section’s question to each piece of prompt content: does it configure the system, or does the user provide it? Place system configuration in the system prompt and user-provided content in the user prompt.
  Why it matters: This question gives you a direct way to split a prompt into its system and user components.

Key terms: system configuration, system prompt, user prompt, prompt decomposition

6.4.2 Worked example: Decomposing step by step

This section works through splitting a rollout-plan analysis prompt into stable system instructions and a user prompt containing the changing plan.

• Rollout prompt decomposition: Trace how the monolithic rollout-plan prompt is divided: place the stable role, analysis instructions, constraints, and output format in the system prompt, and the request-specific rollout plan in the user prompt template. Explain that each component is placed by asking whether it configures the assistant or supplies user input.
  Why it matters: This split lets the assistant keep consistent analysis behavior while accepting a different rollout plan for each request.

Key terms: monolithic prompt, system prompt, user prompt template, role assignment, constraints, output format

6.4.3 Quick decisions

This section gives a quick rule for placing stable instructions in system prompts and request-specific material in user prompts.

• System and user prompt placement: Distinguish what belongs in the system prompt from what belongs in the user prompt, including the use of delimiters around variable content.
  Why it matters: This rule helps you decide where each part of a chat prompt belongs.

Key terms: system prompt, user prompt, delimiters, variable content

6.4.4 When to use architectural separation

This section explains when a simple combined prompt is enough and when separating system instructions from user inputs is worth the added complexity.

• Architectural separation decision: Distinguish tasks suited to a simple combined prompt from those that warrant system/user separation, using frequency of use, multiturn interaction, consistency, and maintenance needs.
  Why it matters: It helps you avoid needless prompt architecture without sacrificing consistency in a production system.
• Reusable email prompt structure: Describe how the high-volume email example separates shared writing standards from customer-specific details, and why that arrangement helps maintenance.
  Why it matters: Keeping shared standards apart from changing customer details makes a high-volume email workflow easier to update.

Key terms: simple combined prompts, system/user separation, architectural separation, system prompt, user prompt template, Customer Context, standards

6.4.5 Common mistakes

This section shows four common prompt-decomposition mistakes and how to keep stable instructions in system prompts while putting changing, clearly delimited data in user prompts.

• Stable instructions without duplication: Explain why recurring task, format, and tone instructions belong in the system prompt rather than being placed in or repeated by each user prompt.
  Why it matters: Keeping stable instructions in one place makes repeated requests easier to maintain consistently.
• Delimited user context data: Explain why changing context data in a user prompt should be enclosed in delimiters, as the customer-feedback example does.
  Why it matters: A clear boundary helps the model treat supplied content as material to analyze rather than directions to obey.
• Variable placement and caching: Explain why company-specific variables should go in the user prompt when the system prompt can remain general.
  Why it matters: Keeping changing values out of the system prompt when possible avoids unnecessary cache inefficiency.

Key terms: system prompt, user prompt, instructions, output format, constraints, context data, delimiters, customer feedback, variables, cache efficiency

6.4.6 Hands-on practice

This hands-on section asks readers to separate stable assistant behavior from changing user inputs and to justify when a short monolithic prompt or a system–user pair is appropriate.

• System and user prompt separation: Apply the question of whether content configures the assistant or is provided for a particular task when splitting a prompt. Put stable behavior and response format in the system prompt, and changing details in the user prompt, delimiting variable blocks when appropriate.
  Why it matters: This separation lets the same assistant behavior be used with new task details without mixing the two.
• Prompt architecture choice: Justify choosing a short monolithic prompt or a system–user prompt pair for a given scenario, using the one-time Docker Compose request, weekly summaries, and multiturn API support as cases.
  Why it matters: The choice should fit the use case instead of adding prompt structure by default.

Key terms: system prompt, user prompt, monolithic prompt, delimiters, architectural decision

6.5 Summary

Summarizes how chat message types divide prompt content, how to decompose system and user prompts, and when that separation is worth using.