Writing a system prompt that actually works

The system prompt is the invisible set of instructions that shapes every conversation your users have with Claude. Get it right and Claude is consistently useful, on-brand, and appropriate. Get it wrong and you'll spend months troubleshooting outputs that never quite work.

Most system prompts have one of two problems: they're too vague to change Claude's behaviour meaningfully, or they're so long that Claude starts ignoring parts of them. Here's how to write one that actually works.

What a system prompt can and can't do

A system prompt can:

• Define Claude's role and persona
• Set the context Claude is operating in (your product, your users, their goals)
• Establish output format preferences (length, structure, tone)
• Tell Claude what to focus on and what to avoid
• Give Claude specific information it needs (your product's features, your company's policies)

A system prompt can't:

• Guarantee Claude will never deviate from instructions
• Override Claude's core values and safety behaviours
• Make Claude competent at things it's not competent at
• Substitute for giving Claude the actual information it needs at query time

This last point matters. A system prompt that says "always provide accurate product information" does nothing useful unless Claude actually has the product information available — either in the system prompt itself or connected via Connectors or RAG.

The structure that works

Start with context, not rules.

Before you tell Claude what to do, tell it where it is and who it's talking to. "You are a customer support assistant for Acme Inc. Acme makes project management software for construction teams. The people you're talking to are project managers and site supervisors, typically non-technical users who need quick, practical answers."

That three-sentence context does more work than ten bullet points of rules. Claude now has a frame for every decision it makes.

Then: persona and tone. How should Claude sound? Not adjectives ("professional, friendly, clear") — specifics. "Write like a knowledgeable colleague, not a formal customer service rep. Use short sentences. Avoid filler phrases like 'Great question!' Match the user's energy."

Then: what Claude should do. The specific tasks it's there to handle.

Then: what Claude should not do. Keep this short — a long list of prohibitions often produces overly cautious behaviour. Cover the important cases, not every edge case you can imagine.

Finally: format guidance. "Keep responses under 150 words unless the user asks for more detail. Use bullet points for lists of more than three items. Don't use markdown headers."

Common mistakes

Writing rules instead of context. "Always be helpful" is a rule. "Users are typically frustrated by the time they contact support — acknowledge that before solving" is context. Context produces better behaviour.

Being vague about format. "Respond appropriately" means nothing. "Keep responses to 2-3 paragraphs, always end with a question that moves the conversation forward" means something specific.

Not testing it. Write ten representative queries. Run them through Claude with the system prompt. Read the outputs as if you're a user, not a developer. Fix what feels off. Repeat.

Setting it and forgetting it. Your product changes, your users' questions change, edge cases emerge. Treat the system prompt as a living document, not a one-time configuration.

The sign of a good system prompt

Claude produces outputs that feel like they came from the same assistant, regardless of who wrote the query or what they asked. Consistency is the goal. If your system prompt produces wildly different results depending on how the question is phrased, it needs more work.

---

Further reading

• Prompt engineering guide — Anthropic Docs