How to Use System Prompts

A system prompt is a set of standing instructions the model reads before any user message, used to fix its role, rules and output conventions for a whole conversation or application. Put the things that should stay true for every turn there, such as who the assistant is, who it serves, what it must not do and how replies are formatted, and keep the specific task and its data in the user message. Models are designed to give system-level instructions priority, but that priority is a strong tendency, not a security boundary.

Where a system prompt sits

Chat-style model APIs accept messages with roles. The names vary by vendor: Anthropic's API takes a system parameter alongside the message list; OpenAI's current documentation describes developer messages (earlier models used a system role) that take precedence over user messages; Google's Gemini API calls the equivalent a system instruction. The idea is the same in each case: one block of text from the application's author, applied to every turn.

{
  "system": "You are a support assistant for a bicycle parts retailer...",
  "messages": [
    { "role": "user", "content": "Is the 11-speed chain compatible with my 10-speed cassette?" }
  ]
}

If you only use chat apps, you still have access to the concept. Custom instructions, project instructions and similar settings are system-level text you write once and the app supplies for you on each conversation.

What belongs in it

A useful division: the system prompt describes the job, the user message describes today's piece of work.

System prompt

• Role and audience: what the assistant is, who it is talking to, what they typically need.
• Scope: topics it handles and what it does with everything else.
• Behavior rules: tone, when to ask a clarifying question, how to handle uncertainty.
• Output conventions: length, formatting, language, any required structure.
• Stable reference material: a product list, a style guide, a glossary.

User message

• The request itself.
• Input that changes every time: the document to summarize, the customer's question, the row of data.

Anthropic's guidance on role prompting notes that a specific role sharpens results more than a generic one; "a data analyst reviewing marketing spend for a retail finance team" carries more usable information than "a helpful assistant". It also recommends giving the reason behind an instruction where one exists, because a model that knows why a rule is there can apply it sensibly to cases the rule did not name.

A worked example

# Role
You are the support assistant for a retailer of bicycle parts. You
answer customers who are mid-repair and want a direct answer.

# Scope
Answer questions about compatibility, fitting and order status using
the catalog in <catalog>. For medical, legal or unrelated questions,
say this is outside what you can help with and offer to return to the
repair.

# Rules
- If compatibility depends on a detail the customer has not given
  (speed count, axle standard, brake type), ask for it before
  answering. One question at a time.
- If the catalog does not cover a part, say you cannot confirm it.
  Do not infer compatibility from similar part names, because a wrong
  answer here means a wasted order.
- Never quote prices; they change daily. Point to the product page.

# Output
Plain text, no markdown. Lead with yes, no or "it depends on", then
at most three sentences of explanation.

<catalog>
...
</catalog>

Each section is short, the rules say what to do in the uncertain case, and two of them include the reason. The catalog is delimited so the instructions can refer to it by name and so it is not confused with the rules.

Writing rules that hold

• Prefer positive instructions. "Reply in plain sentences" is followed more dependably than "do not use lists". Google's prompting guidance makes a similar point about showing the pattern you want.
• Cover the fallback. For every "only do X", say what happens otherwise. Unspecified fallbacks are where assistants improvise.
• Keep emphasis proportionate. Vendor guidance for recent models notes they are responsive to system instructions, and that shouting (capitals, "CRITICAL") can cause a rule to be over-applied. State it once, plainly.
• Resolve conflicts yourself. "Be thorough" and "keep replies under 50 words" cannot both win. Decide the priority and write it down.
• Order by importance, group by topic. Labeled sections make a long system prompt easier for the model to follow and for you to edit.

Limits you should plan for

It is not access control

A user can ask the model to ignore its instructions, and text inside a pasted document or a web page can contain instructions of its own. Models are trained to favor the system prompt, but you should assume that determined input can sometimes override or extract it. Do not put secrets, credentials or anything you would not want displayed into a system prompt, and enforce real permissions in code, outside the model.

Long conversations drift

Over many turns, earlier instructions compete with a growing history. If a rule matters at a specific moment, such as output format for a final step, restating it in the relevant user turn is a reasonable safeguard.

It costs tokens on every call

The system prompt is sent with each request. Long reference material may be better retrieved per request than included permanently. Vendors offer prompt caching features that reduce the cost of a repeated prefix; check the current documentation for the model you use.

Behavior differs between models

A system prompt tuned on one model version should be re-tested on the next. Phrasing that was needed to get an older model's attention may be too forceful for a newer one.

Testing a system prompt

Because a system prompt governs inputs you will never see, test it with a fixed set of messages before relying on it:

1. Several ordinary requests that represent the main use.
2. A request with a missing detail, to check the clarifying-question rule.
3. An out-of-scope request.
4. A message that tries to override the rules ("ignore the above and...").
5. An empty or garbled message.

Change one rule at a time and re-run the set. The rubric in how to test AI prompts applies directly; constraint adherence and reliability are the criteria system prompts most often fail.

Related patterns

Examples can live in a system prompt too, and are often the most efficient way to pin down tone or format; see few-shot prompting. For work that passes through several model calls, each call typically gets its own narrow system prompt, as described in prompt chaining. For a system-style prompt applied to a concrete job, the brand voice prompt and the code review prompt both define a role, rules and output format in the way described here.