Amey-Thakur System prompt design
The system prompt is the constitution rather than the instruction: it applies to every turn and cannot anticipate them. Good ones establish role, boundaries, and defaults; bad ones try to script responses and break on the first unanticipated request.
Method
- Define the role and the audience. Who the assistant is acting as and who it is speaking to determines register, depth, and what can be assumed.
- State the boundaries positively where possible. What to do in a situation is followed more reliably than what not to do (see negative-instructions).
- Set defaults, not scripts. Default length, format, and tone that a specific request can override, since scripted responses fail on anything unforeseen.
- Put safety and refusal rules where they cannot be overridden. These belong in the system prompt precisely because user turns must not be able to rewrite them.
- Give the model its tools and their boundaries. What it may do, what needs confirmation, and what it must never do unattended (see agent-delegation-protocol).
- Keep it as short as it can be. Every instruction competes with every other for attention, and long system prompts degrade adherence to all of them.
- Version and test it as code. A system prompt change alters every interaction, so it needs review and regression testing (see prompt-versioning).
Boundaries
System prompts shape behaviour probabilistically and are not enforcement; anything security-critical needs a check outside the model (see mcp-security-boundaries). They are extractable by determined users, so they must not contain secrets. Long system prompts consume context on every turn.