Claude System Prompts: The Complete Guide

What actually belongs in a Claude system prompt, and what should just live in the conversation instead? That distinction trips up more people than the writing itself. A system prompt sets the persistent frame Claude operates within for an entire session or application; the conversation is where specific, one-off requests happen. Mixing the two — cramming task-specific instructions into a system prompt, or repeating persistent rules in every message — is where most Claude system prompts go wrong before they even get to wording.

Quick-Start (Copy This Right Now)

You are [role/identity]. Your purpose is [core function].

Behavior rules:
1. [Specific trigger] -> [specific action]
2. [Specific trigger] -> [specific action]
3. [Fallback rule for situations not covered above]

Constraints:
- [Things this assistant should never do]
- [Escalation rule: when to hand off to a human]

Format:
- [Response length, structure, tone preferences]

Tone: [2-3 words, paired with a concrete example of what that means 
in practice]

What this does: this skeleton separates identity, behavior rules, hard constraints, format, and tone into distinct blocks, which makes each section independently editable and easier for Claude to apply consistently, rather than one long paragraph mixing all five together.

⚡ Pro tip: write your constraints section before your behavior rules, even though it appears after in the final prompt. Thinking through what the assistant should never do first tends to surface edge cases you'd otherwise miss when writing the positive behavior rules.

Understanding the Variables

The "specific trigger -> specific action" format matters more than any other single choice in a system prompt. Vague behavioral guidance ("be helpful," "use good judgment") asks Claude to infer what a specific situation calls for, and that inference can vary conversation to conversation. A concrete trigger — "if the user asks about pricing, direct them to the current rate card, don't quote a number from memory" — removes the inference step entirely.

The fallback rule at the end of your behavior rules is easy to skip and important not to. Without one, Claude has to improvise when a request doesn't match any listed rule, and improvisation is exactly the inconsistency a system prompt is meant to prevent. Something as simple as "if a request doesn't fit any rule above, say so plainly and ask a clarifying question" gives Claude a default instead of a guess.

⚠️ Common mistake: writing tone as an adjective list ("friendly, professional, empathetic") with no concrete anchor. Pair every tone word with a one-line example of what it looks like in practice, or Claude has to guess at your specific interpretation.

Step-by-Step: Building a Complete System Prompt

1. Define identity and purpose in one or two sentences. This isn't the place for a long backstory — it's a job description, not a character bio.
2. List behavior rules as if/then pairs, ordered by how frequently each situation actually comes up. Put your most common edge case first.
3. Write hard constraints separately from behavior rules. Things the assistant should never do (quote unverified statistics, make promises about refunds, give legal or medical advice) deserve their own clearly marked section, since these carry more weight than routine behavior guidance.
4. Specify format expectations explicitly — length, structure, whether to use headers or plain paragraphs — rather than letting Claude infer format from context.
5. Anchor tone to an example, not just adjectives.
6. Add a fallback rule for situations your list doesn't cover.

⚡ Pro tip: test your finished system prompt against a genuinely awkward edge case before deploying it — an angry customer, a request slightly outside scope, a multi-part question that only partially fits your rules. If the prompt handles the edge case reasonably, it'll handle the common cases fine.

Pro-Level Variations

For agentic use cases — a system prompt driving a Claude-based agent that uses tools, not just a chat assistant — add an explicit section on tool-use judgment: when to use a tool versus answer from existing context, and what to do if a tool call fails. Agents without this section tend to either over-use tools for things they could answer directly, or fail silently when a tool call doesn't return what was expected.

For multi-turn customer-facing assistants specifically, it's worth adding an explicit instruction about conversation memory: what the assistant should and shouldn't assume it remembers from earlier in a long conversation, since drift over long sessions is one of the most common failure modes in production system prompts.

For internal tools used by technical teams, consider a section that explicitly tells Claude what level of assumed expertise to write for — a system prompt for a tool used by senior engineers can skip a lot of the explanatory scaffolding that a tool for less technical users would need, and being explicit about that avoids either over-explaining or under-explaining by default.

Troubleshooting Common Issues

If Claude's behavior drifts over long conversations despite a solid system prompt, check whether your highest-priority rules are positioned early in the prompt — instructions closer to the start tend to get referenced more reliably across long sessions than ones buried under formatting details.

If you're seeing inconsistent tone despite a tone section, the fix is almost always to replace adjectives with a concrete example sentence. "Direct and warm" means something different to every reader (and to Claude); one example sentence written in the target tone anchors the interpretation.

If the assistant handles common cases well but breaks down on anything unusual, that's a fallback-rule gap — go back and add an explicit instruction for what to do when no listed rule applies.

Your Turn

Pull up your current Claude system prompt, if you have one, and check it against the five-part skeleton above: identity, behavior rules as triggers, constraints, format, and tone with an example. Most existing system prompts are missing at least one section, usually the fallback rule or the concrete tone anchor — and those two are disproportionately responsible for the drift and inconsistency people complain about.

Once you've got a system prompt structure that holds up across real conversations, not just quick tests, save it in PromptABCD rather than keeping it in a text file you'll lose track of. A system prompt is infrastructure, not a one-off — treat it with the same care you'd give any other piece of your stack.

Actually, the comparison to infrastructure is worth taking further than most teams do. Code gets version control, code review, and a changelog. System prompts driving customer-facing assistants rarely get any of the three, even though a bad edit to one can misroute real customer conversations just as easily as a bad code deploy can break a real feature. Treating your system prompt file with the same rigor — a git history, a second set of eyes before a change ships, a note on why each rule exists — pays off exactly when you need to debug why behavior changed after last week's edit and nobody remembers which line moved.