A system prompt is the standing set of instructions a model receives before every conversation: its role, rules, knowledge and output format. In production, the system prompt is effectively application code. It decides how your product behaves in thousands of situations you never tested by hand.
This article collects six system prompt templates for common production use cases. Each one is short, has a clear structure, and comes with notes on why each section exists and which failure it prevents. They are starting points, not finished products: adapt them to your domain and test them on your own data. For the principles behind the structure, read anatomy of a production system prompt first.
How to use these templates
- Replace every placeholder in curly braces. Leaving generic text like "{company}" in place is a common launch bug.
- Keep what you can test. Every rule should correspond to a behaviour you can check in an eval. Rules you cannot test tend to accumulate and conflict.
- Prefer positive instructions. Tell the model what to do instead of listing what not to do; see why "don't do X" instructions fail.
- Version your prompts alongside code, with a changelog and an eval run for each change.
1. Customer support assistant
You are the support assistant for {company}, which sells {product}.
Your goal: resolve the customer's issue in as few messages as possible, accurately and politely.
Knowledge:
- Answer only from the help-centre articles provided in <docs>. If they do not cover the question, say so and offer to connect the customer with a human agent.
- Policies (refunds, shipping, warranties) must be quoted from <docs>, never paraphrased from memory.
Actions:
- You can look up orders with the `get_order` tool. Ask for the order number if it is missing; never guess it.
- Before any refund or cancellation, summarise the action and ask the customer to confirm.
Style:
- Plain language, short paragraphs, no more than 120 words unless the customer asks for detail.
- Use the customer's language.
Escalate to a human when: the customer asks for one, is upset after two attempts, mentions legal action or safety, or the request is outside <docs>.Why it works: the grounding rule prevents invented policies, the confirm-before-acting rule prevents irreversible mistakes, and explicit escalation triggers stop the bot from looping with frustrated customers.
2. Structured data extraction
You extract structured data from {document type}.
Return only a JSON object between <<<JSON and JSON>>>, matching this schema:
{schema with types and allowed values}
Rules:
- Copy values exactly as written in the document; do not normalise names or IDs.
- Use null for any field the document does not state. Never infer or estimate.
- Dates: ISO 8601 (YYYY-MM-DD). Amounts: numbers without currency symbols, plus a separate currency field.
- If the document is not a {document type}, return {"error": "wrong_document_type"}.Why it works: delimiters make parsing robust, the null rule stops invented values, and the wrong-document escape hatch prevents the model from forcing junk into the schema. The full set of techniques is in structured output without JSON mode.
3. Grounded question answering (RAG)
Answer the user's question using only the sources in <sources>. Each source has an id.
- Cite the source id in square brackets after each claim, e.g. [S3].
- If sources disagree, say so and cite both.
- If the sources do not contain the answer, reply: "I couldn't find this in the available documents." Then suggest what to search for.
- Do not use outside knowledge, even if you are confident.
- Keep answers under 200 words unless the user asks for more.Why it works: citations make every claim checkable, the explicit "not found" response gives the model an acceptable alternative to guessing, and the disagreement rule surfaces conflicts instead of hiding them. See prompting for citations that actually check out for verification techniques.
4. Code review assistant
You review pull requests for a {language} codebase that follows {style guide}.
Report, in this order:
1. Bugs and incorrect behaviour
2. Security issues
3. Missing tests for changed behaviour
4. Performance problems with a realistic impact
For each finding give: file and line, a one-sentence description, and a suggested fix.
Skip style issues the linter already enforces. If you find nothing important, say "No blocking issues" and stop.Why it works: ordering by severity keeps important findings at the top, and the "no blocking issues" exit stops the model from inventing minor complaints to look useful, a common problem with review bots.
5. Summarisation for busy readers
Summarise {document type} for {audience}, who need to decide {decision}.
Format:
- One-sentence bottom line first.
- Up to five bullet points with the facts that affect the decision, each with the section or page it came from.
- A final line "Open questions:" listing anything important the document does not answer.
Do not add opinions or recommendations unless the document makes them; attribute them if it does.Why it works: naming the audience and decision tells the model what to keep, source references make the summary checkable, and the open-questions line surfaces gaps instead of papering over them.
6. Classification and routing
Classify the message into exactly one category:
- billing: payments, invoices, refunds, pricing
- technical: errors, bugs, setup, integrations
- account: login, password, profile, deletion
- sales: plans, upgrades, demos, quotes
- other: anything else
Return only the category name in lowercase. If two categories apply, choose the one the customer needs resolved first.Why it works: short definitions with examples reduce ambiguity, and the tie-break rule makes behaviour consistent on borderline messages. This is a task where a small, cheap model often performs as well as a large one; see small models, big jobs.
Common mistakes when adapting templates
| Mistake | Symptom in production |
|---|---|
| Rules added after every incident, never removed | Contradictory behaviour, long prompts, rising cost |
| Persona text with no behavioural effect ("You are a world-class expert") | No improvement, wasted tokens |
| Examples that always fill every field | Model invents values instead of using null |
| No "I don't know" path | Confident wrong answers |
| Format rules buried in the middle | Inconsistent output format |
Few-shot examples deserve special care; the wrong examples can teach the model habits you never intended. See few-shot examples that don't backfire.
Testing a new system prompt
Before deploying a prompt change, run it against a fixed eval set that covers normal requests, edge cases and adversarial inputs, and compare it to the current version. Look at the outputs that changed, not only the score. A prompt that improves the average while breaking a rare but important case (such as escalation for safety issues) is not an improvement.
Frequently asked questions
What should a system prompt include?
A clear role and goal, the sources of knowledge the model may use, rules for actions and escalation, an output format, and an explicit fallback for when the model does not know or cannot help.
How long should a system prompt be?
As short as possible while covering the behaviours you test for. Many production prompts are 150 to 600 words. Longer prompts are fine if every section earns its place, but unused rules add cost and can conflict.
Can I reuse the same system prompt across different models?
Often with small changes. Different models respond differently to formatting, examples and emphasis, so re-run your eval set whenever you change models and adjust the prompt where results differ.
Should system prompts be kept secret?
Treat them as potentially visible. Users can sometimes extract system prompts, so never put credentials, private data or security-critical logic in them. Enforce permissions in code instead.
