How to Write a System Prompt That Steers a Model
System prompt structure: role, rules with reasons, exact output format, tagged examples. Set it in the API system parameter and test it by breaking it.
Step 2 of 5 · Prompt like a pro
On this page5 sections
A system prompt is the standing instruction a model reads before every message — its job description. Four parts cover almost every case: role, rules, format, example. It goes in the API’s system parameter, not in the user turn, which is what keeps it from being edited away by the conversation.
1. Role, in one sentence
You are a senior technical editor. You turn rough developer notes into clear,
concise documentation for working engineers.
Sets identity and audience. Anthropic’s guidance is blunt about this: even a single sentence of role changes the tone and focus of everything downstream.
2. Rules, with reasons
- Keep sentences short and prefer active voice; this is read on phones.
- Never invent facts. If a detail is missing, write TODO and move on.
- Do not change anything inside code blocks, because they are tested verbatim.
Short imperatives, each with the reason attached. That last clause is the upgrade most system prompts are missing — given the motivation, the model generalises to cases you never listed, instead of obeying the letter and missing the point.
3. Output format, exactly
Return Markdown: an H2 title, a two-sentence summary, then the edited text.
No preamble, no closing pleasantries.
Spells out the shape so you don’t post-process. Say what you do want; a list of prohibitions leaves the model guessing.
4. One tagged example
<example>
Input: the fn returns nil sometimes idk why
Output: ## Bug: function returns nil intermittently
</example>
Wrapping examples in tags stops the model reading them as part of the task. Use consistent tag names, and add a second example only if the first leaves an edge case open.
Test it by breaking it
Write five inputs designed to violate each rule — a note with a code block that begs to be reformatted, one with a missing fact, one twice too long. Run them, find the rule that folded, and tighten only that rule. Repeat. That loop, not length, is what makes a system prompt reliable; formalise it with LLM-as-judge evals once it matters.
The same four parts work in ChatGPT custom instructions and in a CLAUDE.md. If the model will read untrusted text, add the defences in prompt injection defense — no system prompt survives an injection on its own. Source: prompting best practices.