How to write a system prompt

What is a system prompt?

A system prompt is a persistent instruction that applies to an entire conversation rather than to one message. Most chat models weight it more heavily than user turns and keep it in context throughout, which makes it the natural home for anything that should hold for every exchange.

The practical distinction is simple: if it should still be true on turn fifty, it belongs in the system prompt. If it only applies to this one request, it belongs in the user message.

What belongs in a system prompt and what does not?

A common mistake is loading the system prompt with information that changes per request — a customer name, an order number, today's data. It bloats every turn, and it means the system prompt has to be rebuilt for each conversation rather than written once and reused.

How long should a system prompt be?

Long enough to cover behaviour that would otherwise be wrong, short enough that every line is doing work. Production system prompts commonly run several hundred words. What matters is that each instruction is there because something went wrong without it.

A useful discipline: when you add a rule, note the failure that prompted it. Rules added speculatively accumulate, contradict each other, and are never removed because nobody remembers what they were for.

How do you stop a system prompt being ignored over a long conversation?

Prompt drift is the gradual loss of adherence as a conversation grows. The persona slips, formatting rules stop being followed, and a constraint stated at the start is outweighed by twenty turns of recent context.

• Put the non-negotiable rules last in the system prompt, where they get more weight.
• State rules as behaviour, not aspiration. "Never promise a delivery date not present in the context" survives better than "be careful about delivery dates".
• Re-inject critical constraints into the latest user turn for long conversations, if your application controls the messages.
• Keep the rule count small. Twelve rules are followed more reliably than forty, because forty inevitably contain conflicts.

Should you tell a model to keep its system prompt secret?

You can, and it will help a little, but you should not rely on it. System prompt leaks are routine — a determined user extracts the instructions, and instructions telling the model to refuse are themselves just more text that can be argued with.

Treat every system prompt as public. Anything genuinely secret — API keys, internal URLs, unannounced pricing, unpublished policy — must not be in the prompt at all. Not because leaks are certain, but because the cost of the leak is entirely yours and the defence is unreliable.

What does a well-structured system prompt look like?

You are the support assistant for a UK bicycle retailer. You answer
customer questions about orders, returns and product fit.

What you know:
- Returns are accepted within 30 days, unused, with proof of purchase
- Delivery is 2–4 working days to UK mainland
- You cannot see order status, payment details or stock levels

How you answer:
- Plain British English. No exclamation marks, no "I'd be happy to"
- Address every question asked, in the order asked
- Two short paragraphs maximum unless the customer asks for detail

What you never do:
- Never state a delivery date, refund amount or stock level. You cannot
  see those. Say what you can check and who can check the rest.
- Never invent policy. If it is not listed above, say you will check.
- Never continue if the customer reports a safety issue with a bike.
  Say a human will contact them and stop.

If you do not know something, say so plainly and say what happens next.

Note the structure: identity, then facts, then style, then hard boundaries, then the fallback. The boundaries are last and stated as absolutes, and each one exists because getting it wrong would be expensive.