liveBook · Manning

System prompt

As explained in Prompt Engineering in Practice

A system prompt is a prompt containing stable instructions that define a model's behavior across interactions.

A system prompt is the stable configuration for a chat assistant. It defines the role, task, procedures, constraints, output format, and communication style that should carry across interactions. A user prompt supplies the question or data that changes with each request; an assistant message is the model’s response. A system prompt does not run by itself: a conversation needs a user message. section 6.1.2 section 6.2

To split a combined prompt, ask of each part: “Does this configure the system, or does the user provide it?”

  • Put role and expertise, task instructions, procedures, boundaries, static background, style, and output specifications in the system prompt. Give it one well-defined responsibility. section 6.2.1 section 6.4.3
  • Put the specific request, changing context, input parameters, and documents in the user prompt. Delimit variable content so it is identifiable as data rather than instructions. section 6.1.2 section 6.4.5
  • Keep the system prompt static when practical. Separating repeated instructions from variable input also makes standards easier to update; repeated static content may qualify for provider-specific prompt caching. section 6.5 section 6.1.2

Issue-creation assistant

System prompt: “Role: Experienced technical project manager. Task: Turn task descriptions into actionable issues. Constraints: Use professional language; do not invent unsupported implementation details. Output: A title under 10 words, followed by a description covering context, objective, steps, and acceptance criteria.” User prompt: “The homepage search box does nothing when users press Enter. Investigate the cause.” The issue-writing standard stays fixed while each problem report changes. section 6.2.3

Use separate system and user prompts when many requests need identical behavior or instructions need independent maintenance. A combined prompt can be sufficient for a few one-off outputs. Do not repeat system instructions in every user message: repetition creates opportunities for drift. Check constraints for conflicts, too. An instruction to be “as helpful as possible” can undermine a prohibition on disclosing individual records; define the permitted scope explicitly instead. section 6.4.4 section 6.4.5 section 10.3.2

How Prompt Engineering in Practice covers it

How deep it goes
Specifies components, placement rules, mistakes, and worked decompositions without descending into model internals.
Examples
Uses issue creation, daily work reports, build triage exercises, and an HR policy conflict.
What it assumes
Assumes familiarity with prompt templates and introduces system, user, and assistant message roles.
What you can do after
Build it from scratch by separating stable instructions from variable input and specifying constraints and output format.
How it connects
Connects system prompts to user messages, assistant messages, prompt templates, delimited input, and prompt caching.

Also explained in

Compare how 2 books explain system prompt →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Prompt Engineering in Practice. The section links point to the parts of the book it draws on.