System Prompt: How to Write One (With Examples)
In short
A system prompt is a standing instruction that sets the model's role, rules and output format once for the whole conversation; a user prompt is the specific request you make here and now. The system prompt is written by the developer or the owner of the assistant, and users normally never see it. A working structure has five blocks: role, function, behavior rules, output format and boundaries ("what not to do"). Below: a plain-language definition, ready-made examples for five roles (support bot, editor, code reviewer, analyst, mentor), a "bad vs good" table, and an honest breakdown of the differences between Claude, ChatGPT and Gemini. If you need templates for ordinary requests, they're in the complete prompting guide and in the arsenal of ready-made cards.
What is a system prompt, and how does it differ from a user prompt?
A system prompt (also called a system instruction) is text sent to the model before the conversation starts, and it stays in force as long as the session lives. It answers the question "who are you and by what rules do you work", not "what should you do right now".
A user prompt is what a person types into the input field: a question, a task, some data. It changes from message to message; the system prompt stays the same.
A simple analogy: the system prompt is an employee's job description, the user prompt is the specific ticket that came in today. The job description is written once, the tickets keep coming.
Technically the model sees both texts together, and the system prompt takes priority: if the system says "do not give medical diagnoses" and the user asks for a diagnosis, the model will refuse or redirect. But priority is not armor. Prompt injection is when a cleverly crafted user request slips past the system rules. So treat a system prompt as a behavior tool, not a security control: never put secrets, keys or passwords in it.
What a system prompt is made of: the structure
A system instruction is easiest to assemble from five blocks, going from general to specific:
- Role — who is answering and in what domain. Not "a helpful assistant", but "a support bot for a hosting provider, answering questions about plans and setup".
- Function — what the assistant does and for whom. One or two sentences about the main job.
- Behavior rules — 3-5 explicit rules: what to stick to, what to avoid, how to act when it doesn't know something.
- Output format — length, structure, language, markdown or plain text. The most underrated block: without it the model picks a format on its own.
- Boundaries — what is forbidden and what to do in edge cases ("if you don't know, say so, don't make things up").
User requests get shorter after this: everything permanent has already moved into the system prompt. For a detailed breakdown of how to frame an ordinary request, see the guide How to brief an agent so it actually understands.
Bad vs good system prompt: what's the difference?
The difference is easiest to see line by line. On the left, typical mistakes; on the right, how it should be done:
| What we look at | Bad system prompt | Good system prompt |
|---|---|---|
| Role | "You are a helpful assistant" | "You are the support bot for service X, answering questions about plans and setup" |
| Rules | Absent or vague generalities | 3-5 explicit rules: what to do and what not to do |
| Format | Not specified | "Answer in 4 sentences or fewer, no markdown" |
| When it doesn't know | The model invents an answer | "If you don't know, say so and hand off to a human agent" |
| Tone | ALL CAPS, "MANDATORY!!!" | Calm wording, no shouting |
| Data | Keys and secrets pasted into the text | Role and rules only; secrets stay outside the prompt |
The main takeaway from the table: a good system prompt is specific and verifiable. The model cannot act on "be helpful"; it can act on "answer in 4 sentences or fewer and don't invent facts".
System prompt examples for five roles
Below are compact starting points. Fill in the square brackets with your own details. All of the examples work equally well in any language the model handles confidently.
1. Support bot
You are the support bot for [service name]. You help with plans, billing
and basic setup.
Rules:
- Answer only questions about the service. Off-topic: politely steer back.
- If you don't know the answer, or the question is about money in the
account, don't invent anything: offer to connect a human agent.
- Friendly tone, 4 sentences or fewer, no filler.
2. Text editor
You are an editor who strips out bureaucratic language and AI cliches.
When editing any text:
- Banned: "in today's world", "it is important to note", "let's dive in".
- Short sentences, facts instead of opinions.
- Return the edited text first, then 2-3 lines on what you changed and why.
3. Code reviewer
You are a strict code reviewer. You check code in this order:
security -> logic errors -> performance -> readability.
- For each finding: line, the issue, how to fix it, severity high/medium/low.
- You never rewrite the whole file. If there are no problems, you say so
instead of inventing some.
4. Data analyst
You are a data analyst. You work only with what is actually in the data.
- Back every conclusion with a specific number from the table.
- Never guess at values: if there's not enough data, say so directly.
- Format: conclusion -> supporting number -> what to check next.
5. Mentor
You are a mentor teaching [subject] to a beginner.
- Explain in plain language, illustrate every term with an example.
- Don't hand over the finished solution right away: ask a leading question first.
- After the explanation, give one small practice task.
More ready-made roles and techniques are in the prompt arsenal and in the collection of ready-made prompts for AI models; the prompting theory is gathered in the knowledge base hub.
How do system prompts differ across models?
The "role -> function -> rules -> format -> boundaries" skeleton is universal, but the details differ. Current as of July 2026:
| Model | How it's set | Quirk |
|---|---|---|
| Claude (Anthropic) | system parameter in the API; projects and styles in the chat UI |
Follows instructions literally, likes XML-tagged blocks |
| ChatGPT (OpenAI) | system/developer role in the API; Custom Instructions |
More tolerant of "intensifiers", markdown formatting |
| Gemini (Google) | system_instruction field in the API; Gems in the chat UI |
A dedicated field purpose-built for the system instruction |
A note on Claude specifically: the current models (as of July 2026, Sonnet 5 and Opus 4.8) follow instructions literally, so caps lock and "CRITICAL!!!" tend to hurt rather than help — the model does exactly what's written, even where it shouldn't. Mark up blocks with XML tags instead. More on this in Prompts for Claude.
For Claude Code and Cursor, the role of the system prompt is played by the CLAUDE.md file — the project's memory: stack, commands, prohibitions, all read at the start of every session. Effectively it's a repository-level system instruction. We packaged rules like these — plan before code, verifiable acceptance criteria, project memory — into the Quest engine, so you don't have to set them up by hand every time.
Common mistakes in system prompts
- Too generic a role. "You are a smart assistant" narrows nothing. The more specific the role, the more predictable the answers.
- No format and no boundaries. Without "how much", "in what form" and "what to do when unsure", the model improvises — and fills the gaps with plausible fabrications.
- Secrets in the text. API keys, passwords and internal data in a system prompt are a leak waiting to happen via injection. Keep them out of the prompt.
- Caps and intensifiers. "MANDATORY!!!", triple exclamation marks. On literal-minded models this skews the answer rather than strengthening it.
- Contradictions. "Be brief" and "explain in maximum detail" in the same prompt: the model will pick one at random.
- Bloat. A model holds two pages of rules worse than five clear ones. Only permanent things go in the system prompt; everything else belongs in the user request.
FAQ
What's the difference between a system prompt and a user prompt, in plain words?
The system prompt sets the rules of the game for the whole conversation (who you are, how you answer); the user prompt is a specific move (a question or a task). The first is set once, the second changes with every message. In a conflict the system prompt wins, but it isn't full protection.
Where do I set a system prompt in ChatGPT, Claude and Gemini?
In the chat interfaces these are separate settings (as of July 2026): in ChatGPT, Custom Instructions and the instructions inside GPTs; in Claude, projects and styles; in Gemini, Gems. In the APIs the system prompt is passed as its own field: Anthropic uses the system parameter, OpenAI the system/developer role, Google system_instruction.
Can I write a system prompt in a language other than English?
Yes. Claude, ChatGPT and Gemini understand and follow instructions in Russian and other major languages without losing quality. Technical terms — library, function and pattern names — are better left as they are.
Does a system prompt protect against rule bypassing?
No, it isn't a security mechanism. It does take priority over the user request, but prompt injection can get around it. Duplicate critical restrictions at the application level, and never store secrets in the prompt text.
How long should a system prompt be?
Exactly long enough to hold the role, the key rules, the format and the boundaries — usually 5-15 lines. What works is density, not length: extra rules dilute the important ones. Start with the minimum and add a line only when you see a mistake repeating.