System Prompts, Roles and Clear Instructions

The system prompt is where an application tells Claude who it is, what it is for and what rules apply. It sits outside the conversation, is sent on every request and, in a well-designed system, changes rarely. The exam tests what belongs in the system prompt, how it differs from the user turn, and the writing habits that make instructions reliable rather than merely present.

The system parameter

In the Messages API the system prompt is a top-level system field, not a message with a system role:

response = client.messages.create(
    model=MODEL,
    max_tokens=1024,
    system="You are a claims assistant for Northwind Insurance. ...",
    messages=[{"role": "user", "content": claim_text}],
)

system may also be an array of text blocks, which is how you attach cache_control to a stable prefix or split static policy from semi-static context. Some current models additionally accept operator instructions as role: "system" entries inside messages for mid-conversation changes without invalidating the cached prefix; check the model documentation before relying on it.

Instructions in system carry operator authority; content in user turns represents the end user and anything they paste. This hierarchy matters for safety: a user message saying "ignore your previous instructions" is weaker than the system prompt, and tool results, which arrive inside user turns, are weaker still. Put rules you need honoured in system, and never let untrusted content be presented as system text.

Role prompting

Assigning a role ("You are a senior tax accountant specialising in cross-border payroll") measurably changes tone, vocabulary, assumed knowledge and caution. The role should be specific and relevant to the task; "You are a helpful assistant" adds nothing. Pair the role with the audience ("answering questions from HR staff who are not accountants") and the purpose, because the model uses all three to decide how much to explain and when to refuse.

What belongs in the system prompt

Belongs in system	Belongs in the user turn
Identity, role, audience	The actual request or question
Standing rules and constraints	Documents, data and retrieved content
Output format defaults	Per-request format overrides
Tool usage policy ("prefer search before answering")	Variable context (today's date, the user's name)
Refusal and escalation policy	Follow-up corrections

Keeping variable data out of system is a caching rule as well as a design rule: a timestamp in the system prompt changes the prefix every request and defeats prompt caching.

Writing clear and direct instructions

Anthropic's first prompt-engineering principle is to be clear and direct: treat Claude as a capable new colleague who knows nothing about your context. In practice:

• State the goal and why it matters. "Summarise for an executive who will decide funding in two minutes" produces a different summary from "summarise".
• Give the success criterion. Length, format, what must and must not appear.
• Prefer positive instructions. "Respond in plain prose" works better than "do not use markdown", because the model has to infer what you want from a prohibition.
• Be specific about edge cases. What to do when information is missing, when the request is out of scope, when two rules conflict.
• Order matters. Put the most important rules first and last; long middles get less weight.
• Use structure. Headings or XML tags separate sections (<rules>, <output_format>) so the model can locate them.
• Avoid over-prescription. Recent models follow instructions closely; a prompt written to bully an older model into compliance can make a newer one rigid or verbose. Say what you want once, clearly.

A quick test: show the prompt to a colleague with no context and ask them to do the task. Where they would ask a question, the model is guessing.

Example

You are the support assistant for Lumen, a project-management SaaS.
Audience: paying customers, mostly non-technical team leads.

<rules>
- Answer only from the provided documentation. If the answer is not there,
  say so and offer to open a ticket.
- Never speculate about pricing or unreleased features.
- Escalate to a human (call escalate_ticket) when the customer reports
  data loss or a security concern.
</rules>

<output_format>
Short paragraphs. Numbered steps for procedures. No marketing language.
</output_format>

Everything variable (the documentation excerpts, the customer's message) arrives in the user turn.

Common failures

Instructions that conflict with each other, instructions buried in a 3,000-word wall of text, rules that depend on information the model does not have, and formats described in words when an example would be unambiguous. Each shows up as inconsistent behaviour that is tempting to blame on the model.

Exam focus

• The system prompt is the top-level system parameter, carries operator authority and should contain identity, standing rules and defaults; variable data belongs in user turns.
• Role prompting works best when the role, audience and purpose are all specific.
• Clear and direct means stating the goal, success criteria and edge-case behaviour, preferring positive instructions over prohibitions.
• Volatile content in system breaks prompt caching; keep it stable.
• Tool results and user text sit below the system prompt in authority and must never be injected as system text.
• Over-prescriptive prompts written for older models can degrade newer models; say it once, clearly.