On this page
A system prompt is a set of instructions the model reads before any user message. It sets the role, rules, tone, and output format for the whole conversation, so you don't repeat them every time. If you want consistent answers from ChatGPT, Claude, or Gemini, get this right first.
System prompt vs user prompt
The system prompt is the standing brief. The user prompt is the task at hand.
Think of hiring a contractor. The system prompt is the onboarding document: who you are, how you work, what the house rules are. The user prompt is the Tuesday request: "Draft a reply to this customer." The contractor reads the first once and applies it to every request after that.
In practice, the difference looks like this:
System prompt: persistent, written by the person building or configuring the assistant, usually hidden from the end user.
User prompt: changes every turn, written by whoever is chatting.
Priority: most models weight system instructions more heavily when the two conflict, but this is a tendency, not a guarantee. Test it on the model you use.
A useful rule for deciding where something goes: if you'd want it true for every request, it belongs in the system prompt. If it only matters for this one task, put it in the user prompt.
Where you actually set a system prompt
Where you write it depends on the tool.
In the API
Developers pass the system prompt as a separate field or message with a system role. Exact parameter names differ between providers, so check the docs for the model you call. This is the cleanest setup because the instructions stay fixed while user messages change.
In ChatGPT
The ChatGPT system prompt that OpenAI ships is not something you can edit. What you can edit are the layers on top: custom instructions and the instructions field inside a custom GPT or project. Those act as your system prompt in practice. Which of them exist for you depends on your plan and the current interface.
In Claude
The same logic applies to the Claude system prompt. Anthropic's own prompt for its apps is theirs. You control the system field in the API, and project instructions or style settings in the Claude app. The wording differs from ChatGPT, but the job is the same.
In Claude Code and other coding tools
The built-in Claude Code system prompt is managed by the tool. Your lever is the project instructions file the tool reads at the start of a session. Treat that file as your system prompt: it should hold build commands, code style, and things the agent must never touch. Keep it short. A long file full of edge cases gets ignored in practice.
In a chat window with nothing to configure
Paste the standing instructions as your first message and say they apply for the whole conversation. It's weaker, because long chats can drift away from it, but it works for a one-off session.
What a good system prompt contains
Most weak system prompts are either one line ("You are a helpful assistant") or a wall of rules nobody can follow. Aim for five parts, each a few lines.
Role and audience. Who the model is and who it's talking to. "You are a support agent for a payroll product, writing to small-business owners who aren't accountants."
Scope. What it should handle and what it should decline or hand off.
Rules. The few things that must always or never happen. Keep these to the ones you've actually seen go wrong.
Tone and format. Length, structure, voice. Be specific: "Replies under 120 words, no bullet points, no exclamation marks."
What to do when unsure. Ask a question, say it doesn't know, or escalate. Without this, models guess confidently.
Skip the pep talk. Lines like "You are a world-class expert" add little. A concrete constraint beats a flattering adjective every time.
A copy-ready system prompt template
Fill in the brackets and paste it into the system field, custom instructions, or project instructions.
You are [role] working for [company or team]. You are writing for [audience], who [what they know or need].
Your job:
- [Main task 1]
- [Main task 2]
Out of scope:
- [Topic or request to decline]
- When asked about these, say so briefly and point to [where to go instead].
Rules:
- Always [rule that has mattered in the past].
- Never [mistake you have seen the model make].
- Use only the information given in the conversation or in the reference material below. If something is missing, ask one clarifying question instead of guessing.
Style:
- Tone: [for example, direct and friendly, no jargon].
- Length: [for example, under 150 words unless asked for more].
- Format: [for example, plain paragraphs, no headings].
Reference material:
[Paste policies, product facts, or style guide excerpts here.]
Worked example: from vague to usable
Say you run customer support for a small invoicing app and want drafts for refund requests.
Before:
You are a helpful customer support assistant. Be polite and help customers with refunds.
Give this a message like "I was charged twice, fix it now," and you tend to get a long apology, a vague promise, and sometimes an invented refund policy. The model has no policy to follow, so it makes one up.
After:
You are a support agent for Ledgerly, an invoicing app for freelancers. You write to customers who are often stressed about money and have little time.
Your job:
- Draft replies to billing and refund questions for a human agent to review.
Out of scope:
- Legal advice and tax questions. Say a human will follow up.
Rules:
- Refunds are available within 30 days of the charge. After that, offer a credit and flag the ticket for a manager.
- Never promise a refund date. Say it will be processed by the billing team.
- If the customer reports a duplicate charge, ask for the last four digits of the card and the dates of both charges.
- If any detail is missing, ask one question instead of guessing.
Style:
- Tone: calm and direct. One short apology at most.
- Length: under 120 words.
- Format: plain paragraphs, signed "Ledgerly Support".
Same message, new result: a short reply that acknowledges the double charge, asks for the card digits and both charge dates, and says the billing team will process any refund. No invented policy, no five-sentence apology. The 30-day rule is an example I made up for this post. Use your real policy.
What changed: the model got facts to rely on, a fallback for missing information, and a hard limit on length. Each of those fixes a specific failure from the first version.
Mistakes that make system prompts worse
Contradictions. "Be concise" next to "Always explain your reasoning in detail" forces the model to pick. Read the whole prompt once, looking only for conflicts.
Stacked patches. Every bad output tempts you to add another rule. After ten of them, nobody knows which line does what. When you add a rule, check whether an older one can go.
Negative-only rules. "Don't be formal" says what to avoid but not what to do. Pair it with the target: "Write the way you'd email a colleague."
Secrets you rely on staying secret. Users can often coax a model into repeating its instructions. Don't put API keys or anything sensitive in a system prompt.
Testing on one input. A prompt that handles your favourite example can still fail on the angry customer or the empty message. Run at least five inputs, including an awkward one.
Treat the system prompt like code
The prompt you write on Monday is rarely the one you ship. You'll tweak a rule, tighten the length, add a policy. If those edits live in a chat window or a shared doc named "final_v3", you lose track of what changed and why quality dipped.
Save the prompt somewhere it can be versioned. In PromptPal, you can store it in your prompt library, keep each revision, and see what changed between versions, which is how you catch the edit that broke refund replies. The approach is explained further on the prompt version control page.
If several people maintain the same assistant, shared access matters more than anything else here. A team workspace keeps one agreed version instead of five private copies.
For wider context on how system prompts fit with the other material you give a model, such as documents and tool output, see Context Engineering Is Not Prompt Engineering.
A quick testing routine
Write the prompt using the template above.
Collect five real inputs: two typical, one vague, one hostile or off-topic, one with missing information.
Run all five and mark each answer pass or fail against your rules.
Change one thing, then rerun all five. If you change three things at once, you won't know which one helped.
Save the version that passes, with a one-line note on what you changed.
Behaviour differs between models, so rerun the set if you switch from one to another. A prompt tuned on Claude may need small edits for ChatGPT or Gemini, and the only way to know is to test it.
Next step
Start with the template above, then save it as your first versioned prompt. You can browse ready-made starting points in the public prompt library and adapt one to your role.
Stay Updated
Get the latest blog posts and AI prompt engineering tips delivered to your inbox.
