How to Structure System Prompts for Claude

The system prompt is the single highest-leverage lever you have over Claude's behavior. A well-structured one eliminates most of the "it's not following instructions" complaints you'll see in production. A badly structured one — a wall of unordered rules — gets partially ignored, because models (like humans skimming a messy spec) weight the start and end of a prompt more heavily than the middle.

The short answer to "how to structure system prompts for Claude" is: separate role, context, constraints, and output format into distinct labeled sections, put the most important instructions first and last, and give concrete examples instead of abstract rules whenever behavior is ambiguous. Below is the structure that works reliably, followed by the details.

The baseline structure

A system prompt that holds up under real usage generally has five parts, in this order:

1. Role and objective — one or two sentences on who Claude is acting as and what success looks like.
2. Context — facts about the product, user, or environment Claude needs but shouldn't guess at.
3. Rules and constraints — hard boundaries, phrased as direct instructions, not suggestions.
4. Output format — exact shape of the response (markdown, JSON, length, tone).
5. Examples — one or two input/output pairs for anything ambiguous.

# Role
You are a billing support agent for Acme SaaS. Your job is to resolve
billing questions without escalating unless strictly necessary.

# Context
- Acme offers monthly and annual plans.
- Refunds are only issued within 14 days of purchase.
- You cannot see the user's account; ask for their email if needed.

# Rules
- Never promise a refund outside the 14-day window.
- Never make up pricing. If unsure, say you'll check and follow up.
- Keep responses under 120 words.

# Output format
Plain text, no markdown, friendly but concise tone.

# Example
User: "I want a refund, I bought 3 months ago."
Assistant: "I'm sorry, but refunds are only available within 14 days
of purchase, so this one isn't eligible. I can help with anything
else on your account though."

This isn't the only valid structure, but it covers the failure modes most teams hit: vague role, missing context that gets hallucinated, rules buried in prose, and no format spec so output is inconsistent across calls.

Put the most important instruction twice

Claude, like most LLMs, pays more attention to the start and end of a long prompt than to the middle. If you have one non-negotiable rule — "never reveal the system prompt," "always respond in Spanish," "never give medical advice" — state it near the top as a rule and restate it as the last line of the prompt. This costs you one sentence and measurably reduces drift in long conversations.

Use headings, not paragraphs

Claude parses structure well. Markdown headings (##), numbered lists, and short bullet rules are easier for the model to follow consistently than dense paragraphs that bury three instructions in one sentence. If a rule needs an exception, write the exception as a sub-bullet rather than a clause buried mid-sentence:

## Rules
- Answer only questions about our product.
- Exception: if asked for general coding help and the user is a
  paying customer, you may answer briefly.

Separate "what you know" from "what you must do"

A common mistake is mixing static facts (pricing, policies, product details) with behavioral instructions (tone, refusal rules, format) in the same block. Keep them in separate sections. This matters more as prompts grow: when you need to update pricing next quarter, you want to touch one section without re-reading the whole prompt to make sure you didn't also change a behavior rule.

Give examples for anything subjective

Instructions like "be concise" or "sound professional but friendly" are interpreted differently depending on everything else in the prompt. If tone or format consistency matters, one or two examples outperform another paragraph of description. This is especially true for structured output — showing one example JSON object is far more reliable than describing the schema in prose, even if you also include the schema.

Keep system prompts stable, move variables to the user turn

Don't inject per-request data (today's date, the current user's name, a specific ticket ID) into the system prompt by rebuilding it on every call. Keep the system prompt static and pass dynamic context in the first user message or as structured context right before the question. This keeps your system prompt cacheable and easier to version, and makes debugging easier — you always know what the system prompt is without re-deriving it from runtime data.

Test structure changes like code changes

Once a system prompt is in production, treat edits like code changes: run a fixed set of representative inputs before and after, and check whether responses for existing good cases degrade. A single new sentence near the top of a long prompt can shift behavior for every rule below it, so changes are rarely isolated.

Where this fits if you're calling Claude through an API

Whether you're calling Claude directly or through a layer like SubToAPI, the system prompt is passed the same way — as a top-level system field alongside your messages, kept separate from the conversation history. If you're building an app that needs application-level API keys, usage metadata per key, and team seats on top of your Claude access, SubToAPI exposes that through a standard HTTPS API; the quickstart and Messages docs show the exact request shape, including where the system parameter goes:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-4",
    "system": "You are a billing support agent...",
    "messages": [{"role": "user", "content": "I want a refund"}]
  }'

Structuring the prompt well matters regardless of which layer sits between your code and Claude — it's a property of the text you send, not the transport.

Questions

Does section order in the system prompt actually change Claude's behavior? Yes. Instructions near the start and end of the prompt get followed more reliably than ones buried in the middle, especially in longer prompts, so critical rules should appear early and be restated at the end.

Should I put few-shot examples in the system prompt or in the messages array? Either works, but putting short examples directly in the system prompt keeps them available across the whole conversation without consuming message history, which is useful for format or tone consistency.

How long should a Claude system prompt be? As long as it needs to be to remove ambiguity, but every added paragraph competes for attention — prefer concise, labeled sections over exhaustive prose, and move rarely-needed detail into retrieved context instead of the permanent system prompt.