Overview
System prompt design patterns are reusable structures for the stable, role-and-policy instruction sent on every turn. The system prompt sets identity, scope, constraints, and output contract; the user prompt carries the task. Getting the system layer right is what makes behavior consistent across requests. This page catalogs the patterns; for what belongs in system versus user and the production rules, see system-prompts; for the term itself see system-prompt.
Lead with role and task framing
Open the system prompt by naming the model’s role and its single primary task. “You are a SQL assistant that writes read-only Postgres queries” anchors register, scope, and refusal boundary in one line. Role framing shifts tone and depth measurably; see role-framing and role-priming.
Layer the prompt into labeled sections
Structure the system prompt as named blocks so each concern is editable and the model can attend to it: role, capabilities, constraints, output format, and examples. Labeled sections beat one prose paragraph because they are easier to version and harder for the model to conflate. This is the system-prompt application of prompt-templates.
State constraints as explicit rules
Write what the model must not do as concrete, checkable rules, not vibes. “Never run a statement that writes; refuse and explain” beats “be careful.” Put the highest-stakes constraints first and last, where attention is highest. Negative constraints work better when paired with the positive action to take instead.
Define an output contract
Specify the exact shape of the response: format, length, schema, and what to omit. When the output is consumed by code, require JSON against a schema. An explicit contract is what makes the response parseable on every call; see output-constraints and system-prompts.
Handle ambiguity and refusal deterministically
Tell the model what to do when the request is unclear, out of scope, or unsafe: ask one clarifying question, refuse with a reason, or fall back to a default. Without an explicit rule the model improvises, and the improvisation varies run to run.
Keep the prefix stable and version it
The system prompt is the most cacheable part of the context; keep it byte-stable across calls so it hits the prompt cache, and change it deliberately. Store system prompts in version control next to the code, tag each version, and re-run evals on every edit. A system prompt is code; treat its changes like code changes. See context-engineering.
Pitfalls
- Cramming task-specific detail into the system prompt; that belongs in the user prompt so the system layer stays stable and cacheable.
- Conflicting instructions across sections; the model picks one unpredictably.
- Editing the system prompt without an eval; a wording change can regress behavior silently. See system-message.