How to write a system prompt that actually works

The system prompt is the instruction set Claude reads before every conversation. It defines who Claude is for your use case, what it knows, how it should behave, and what it should never do. Write it well and every user in your Project gets great outputs. Write it poorly and every user gets mediocre ones — and no amount of clever individual prompting fixes a bad system prompt.

Here is the method that produces system prompts that actually work.

Start with four questions

Before you write a single word, answer these:

1. Who is Claude in this context?
Not "a helpful AI assistant" — that is meaningless. Specifically: what role is Claude playing? "A customer support specialist for [Company] who helps draft responses to incoming support tickets." "A marketing copywriter who produces content in [Brand]'s voice." The more specific the role, the more consistent the outputs.

2. Who is Claude talking to?
The user's context changes everything. "Experienced support reps who need Claude to handle volume, not explain basics" is different from "new joiners who need Claude to guide them through the process step by step." Write for your actual audience.

3. What does good output look like?
Pick three examples of output you would be happy sending. What do they have in common? Tone, structure, length, what they include, what they leave out. That is what you are trying to specify.

4. What are the hard rules?
Things Claude must never do in this context. Keep this list short — two or three items. "Never guess at product pricing — say you'll check and follow up." "Never promise a specific resolution timeline." "Never mention competitors by name." Hard rules should be genuinely hard, not everything you are vaguely worried about.

The template

This structure works for most team Projects:

Role: [One sentence describing who Claude is and what it does]

Audience: [Who the user is, their context and level of knowledge]

Tone: [Three adjectives — not "professional and friendly," be specific: "direct, warm but not chatty, assumes the customer is intelligent"]

Always: [Two or three specific positive behaviours]

Never: [One or two hard constraints]

Context: [Key facts Claude needs to know about your company, product, or situation — the things it would otherwise get wrong or have to guess at]

Format: [How responses should be structured — length, use of lists vs prose, headers or no headers]

Total length: 200–400 words. If you are writing more than 400 words, you are either including things that are not truly rules (they are preferences, handle those with examples instead) or you are trying to cover every edge case (impossible — handle exceptions in conversation instead).

The mistakes everyone makes

Writing for edge cases instead of the common case. Your system prompt should optimise for the 80% of interactions, not the 5% of weird situations. Handle edge cases in conversation.

Using vague tone descriptors. "Professional and friendly" describes every corporate AI assistant ever written. Instead: "Write like a senior colleague explaining something to a peer — knowledgeable but not condescending, concise but not terse."

Putting examples in the system prompt. Good examples belong in the Project knowledge base as documents, not in the system prompt. The system prompt is for rules, not demonstrations.

Making it a requirements doc. System prompts are not contracts. They are context. Claude interpolates and applies judgment. Write for a smart colleague who needs orientation, not an edge case reviewer who needs every scenario documented.

Never testing it. A system prompt is a hypothesis. Run it against 10 representative inputs before anyone else uses the Project. Where does it produce the wrong tone? Where does it get facts wrong? Where does it miss the format? Fix those before launch, not after.

How to iterate

When outputs go wrong, diagnose before rewriting:

• Wrong tone? Add a specific example of the right tone in the Context section.
• Wrong facts? Add the correct information to the Project's knowledge documents.
• Wrong format? Add a Format section with explicit structure.
• Wrong scope? Tighten the Role definition.

Most system prompt problems are one of these four. Identify which before you rewrite the whole thing.

The best system prompts are not the longest ones. They are the ones where every sentence earns its place — and the Project owner reviews them every month to remove what no longer applies.