System Prompt
also called System message, Instructions
The standing instructions the user does not see.
A message that sets the model’s role, rules and output expectations before any user turn. It carries more authority than user messages and is the standard place for tone, format and boundaries.
Put stable requirements here and keep it short. Long system prompts are diluted by everything after them, and a rule buried in paragraph nine will be ignored.
Treat it as configuration with a version, not as a paragraph you edit freely. It is the highest-authority text in the request, it sets the shape of everything downstream, and because it sits at the front of the prefix it is also what makes caching work — reordering it invalidates the cache for every request.
Rules that compete with each other
A system prompt has grown to forty bullet points of accumulated policy.
Keep the must-haves few, explicit and at the end, and move everything else into retrieved context or a skill that loads on demand. Instruction following degrades as constraints accumulate and conflict, so a shorter system prompt is usually a more obedient one.
- docsPrompting best practices ↗
The current house guidance on explicit instructions, output constraints, examples, XML structure and role prompting.
- docsPrompt engineering overview ↗
Ties each prompting technique to a success criterion and to empirical evaluation, rather than presenting them as a bag of tricks.
Context
Everything the model can currently see.
Prompt Engineering
The craft of writing instructions a model reliably follows.
Instruction Following
The model’s ability to actually obey what you asked.
Guardrails
Constraints on what the system will do, enforced in code.