System prompts: the instructions the user never sees
The system prompt establishes role, constraints and output format before any user input arrives. Specific, testable instructions with worked examples outperform adjectives, and every rule should be there because something went wrong without it.
The system prompt is the part of the conversation the user never writes and never reads. It sets the frame for everything after it, which makes it the highest-leverage text in most AI features — and the most likely to have been written once, in a hurry, and never revisited.
Behaviour, not personality
"You are a helpful, knowledgeable assistant" does almost nothing. Every one of those adjectives describes a disposition the model already has, and none of them is checkable.
Compare: "Answer in at most three sentences. If the question is not about billing, reply that you only handle billing." Both statements are short. Only the second one has consequences you could write a test for.
Show the shape
Describing a format in prose is a slow way to communicate something a single example conveys exactly. One correct sample output does more to fix structure than a paragraph about it, and it removes the ambiguity your prose did not know it contained.
Separate the rules from the data
Instructions belong in the system prompt; the material to act on belongs in the user message. Mixing them makes both harder to change and creates an obvious injection surface — text that arrives from a user or a document should never be in a position to read as policy.
Mark supplied content clearly, and say in the instructions that content inside those markers is data to be processed, never directions to be followed.
Every rule should have a history
The healthiest prompts are the ones where each line was added in response to something going wrong. That discipline keeps them short and makes them reviewable: if nobody can say what a sentence prevents, it is a candidate for deletion.
Prompts drift the other way by default. They accumulate. Periodically removing a rule and checking whether anything regresses is a real maintenance task.
It is not a security boundary
People will extract your system prompt, and often it is easier than you expect. Write it on the assumption that it may be read.
That means no keys, no credentials, no internal policy you would not publish. Anything that genuinely must be enforced belongs in code that runs before or after the model, where an instruction cannot be talked out of it.
Frequently asked questions
How long should a system prompt be?
As long as it needs to be and no longer. Each rule should trace back to a real failure. A prompt that grew by accretion, where nobody can say what any given line prevents, is usually both too long and less effective than a shorter one.
Can users see the system prompt?
Assume so. Extraction attempts succeed often enough that you should never put credentials, keys or genuinely sensitive policy in one. Enforce security in your own code, not in an instruction.
