The System Prompt Checklist: 12 Sections Every System Prompt Needs
A comprehensive template for production system prompts.
The Prompt Engineering Project March 2, 2025 8 min read
Quick Answer
A system prompt template should include these sections: role and identity definition, core behavioral instructions, input handling rules, output format specification, constraint and boundary definitions, error and edge-case handling, tone and style guidelines, and example interactions. This checklist ensures every system prompt covers the critical elements that drive consistent, reliable model behavior in production.
Most system prompts are missing half of what they need. Teams write a role definition, add a few instructions, maybe throw in an example, and ship it. Then they spend weeks debugging failures that could have been prevented by a section they never thought to include. Edge case handling. Error recovery. Versioning. The unsexy infrastructure that separates a prompt that works in a demo from one that works in production.
This article is the companion piece to "Anatomy of a System Prompt," which goes deep on each section. This one is the quick reference -- the checklist you open before shipping a new system prompt or auditing an existing one. Twelve sections, each with its purpose, its justification, and a concrete example. If your system prompt is missing any of them, it has a gap that will eventually become a bug.
The Foundation: Identity and Scope
The first four sections establish who the model is, what it knows about, what it must do, and what it must not do. These are the load-bearing walls of your system prompt. Everything else builds on them.
1
Role Definition
Establishes the model's identity, expertise level, and perspective. Without this, the model defaults to a generic assistant persona that may not match your product's voice or domain requirements. Example: "You are a senior financial analyst specializing in SaaS metrics. You have 15 years of experience evaluating ARR, churn, and unit economics."
2
Context Scope
Defines the boundaries of what the model should and should not know about. This prevents the model from volunteering information outside its domain or making assumptions about data it does not have. Example: "You have access to the company's Q3 2024 earnings report and the competitive landscape document. You do not have access to internal roadmap data."
3
Core Instructions
The primary task or set of tasks the model must perform. These should be specific, actionable, and ordered by priority. Vague instructions produce vague outputs. Example: "For each support ticket, identify the root cause, classify the severity, and draft a customer-facing response."
4
Behavioral Constraints
Hard limits on what the model must never do. These are your guardrails -- the behaviors that would be unacceptable regardless of the user's request. Example: "Never recommend specific stocks or financial instruments. Never provide medical diagnoses. Never fabricate citations or data points."
Structure and Evidence: Format, Examples, and Edges
A system prompt without examples is a specification without test cases. You are asking the model to guess what good looks like.
1
5. Output Format
Specifies the exact structure, length, and formatting of responses. This is where you define JSON schemas, markdown conventions, section headers, and length constraints. Without it, the model chooses its own format, which changes unpredictably between requests. Example: "Respond in JSON with keys: summary (string, max 100 words), risk_level (low|medium|high), action_items (array of strings)."
2
6. Examples (Few-Shot)
Concrete input-output pairs that demonstrate exactly what a correct response looks like. Examples are worth more than paragraphs of instruction because they show rather than tell. Include at least one typical case and one edge case. Example: Provide a sample ticket with its ideal classification, response, and formatting.
3
7. Edge Case Handling
Explicit instructions for situations that fall outside the normal flow. What should the model do when it encounters ambiguous input, missing data, contradictory requirements, or requests that partially match its instructions? Without this section, the model improvises, often badly. Example: "If the customer's question spans multiple categories, classify under the primary concern and note secondary topics in the notes field."
4
8. Tool Use Guidelines
For models with access to tools or functions, this section defines when to use each tool, in what order, and what to do with the results. Without explicit guidance, models either over-use tools (calling search for every question) or under-use them (answering from memory when they should look things up). Example: "Always search the knowledge base before answering product questions. Use the calculator tool for any numerical comparison."
Operational Sections: Tone, Recovery, Safety, and Versioning
The final four sections handle the operational concerns that most teams overlook until something goes wrong. Tone inconsistency, unrecoverable errors, compliance violations, and untraceable prompt versions are all problems that these sections prevent.
1
9. Tone and Style
Defines the communication personality of the model. This is more than "be professional" -- it includes sentence length preferences, vocabulary level, formality register, and specific phrasing to use or avoid. Without it, tone varies wildly between responses. Example: "Use direct, declarative sentences. Avoid hedging language like 'I think' or 'perhaps.' Technical terms are acceptable; jargon is not."
2
10. Error Recovery
Instructions for what the model should do when it cannot complete the task, encounters malformed input, or recognizes that its output may be unreliable. This section prevents the two worst failure modes: silent hallucination and complete refusal. Example: "If you cannot determine the sentiment with confidence, return sentiment: 'uncertain' and include your reasoning in the notes field."
3
11. Safety and Compliance
Industry-specific and company-specific rules that the model must follow. HIPAA for healthcare, PCI for financial data, GDPR for user data. Also includes your company's internal policies on data handling, content restrictions, and liability language. Example: "Never include PII in log-accessible outputs. Always append the disclaimer: 'This is not financial advice' to investment-related responses."
4
12. Versioning Header
A metadata block at the top of the prompt that includes version number, last-modified date, author, and a brief changelog. This is invisible to users but invaluable for debugging, rollbacks, and audit trails. When a prompt starts failing, the first question is always 'what changed?' The version header answers it. Example: "v2.4.1 | 2025-02-15 | Updated edge case handling for multi-language tickets | Author: ops-team"
The Template in Practice
Here is a minimal but complete system prompt skeleton that includes all twelve sections. In production, each section would be substantially longer, but even at this scale, the structure prevents the most common gaps.
system-prompt-template.txt
# v1.0.0 | 2025-03-01 | Initial release | Author: engineering
## Role
You are a senior customer success analyst for a B2B SaaS platform.
## Context Scope
You have access to: customer usage data, support ticket history, account health scores.
You do not have access to: billing details, internal roadmap, employee records.
## Core Instructions
1. Analyze incoming support tickets for root cause and severity.
2. Draft a customer-facing response.
3. Flag tickets that require human escalation.
## Constraints
- Never promise specific timelines for bug fixes or features.
- Never share internal metrics or account data with the customer.
- Never fabricate workarounds. If unsure, escalate.
## Output Format
Respond in JSON: { severity, root_cause, response_draft, escalate: boolean, notes }
## Examples
[Input]: "Dashboard has been loading for 5 minutes"
[Output]: { "severity": "high", "root_cause": "performance", ... }
## Edge Cases
- If multiple issues are reported, address the most severe first.
- If the ticket is in a non-English language, respond in that language.
## Tool Use
- Search knowledge base before drafting any response.
- Check account health score before recommending escalation.
## Tone
Direct, empathetic, professional. Short sentences. No jargon.
## Error Recovery
If root cause is unclear, set root_cause to "needs_investigation" and escalate.
## Safety
No PII in outputs. Append "Response generated by AI" to all drafts.
Not every system prompt needs all twelve sections at full depth. A simple classification prompt may need only five or six. But every production prompt should at least consider each section and make a deliberate decision about what to include or omit.
Key Takeaways
1
The twelve sections are: Role Definition, Context Scope, Core Instructions, Behavioral Constraints, Output Format, Examples, Edge Case Handling, Tool Use Guidelines, Tone and Style, Error Recovery, Safety and Compliance, and Versioning Header.
2
Examples are the single most impactful section. They show the model what correct output looks like, reducing ambiguity more effectively than any amount of prose instruction.
3
Error recovery and edge case handling prevent the two worst failure modes: silent hallucination when the model is uncertain, and complete refusal when the input is slightly unusual.
4
Version headers cost nothing to add and save hours of debugging when a prompt that was working suddenly stops. Always include them.