How to brief Claude before the conversation starts

Imagine hiring a brilliant contractor. On their first day, you have two choices: throw them in cold and let them figure it out, or spend 20 minutes briefing them — who you are, what matters to your company, what your customers need, how you want them to communicate.

The system prompt is that briefing.

It's a block of text that sits above the user conversation — invisible to your users, but read by Claude before every single message. Whatever you put there shapes how Claude behaves for the entire session.

What goes in a system prompt

A system prompt can contain anything Claude should know or do consistently:

Identity and role. "You are a support assistant for Acme Finance. You help users understand their account activity and guide them through common tasks."

Tone and format. "Keep responses concise. Use plain language. Avoid financial jargon unless the user uses it first."

Constraints. "Only discuss topics related to our product. If someone asks about competitors, acknowledge the question and redirect."

Background knowledge. "Here is our refund policy: [paste full policy]. Apply this when users ask about returns or cancellations."

Output structure. "When recommending an action, always list it as a numbered step."

Why this matters

Without a system prompt, Claude is a generalist — capable of almost anything, optimized for nothing in particular.

With a well-crafted system prompt, Claude becomes a specialist. The same underlying model, shaped to fit your exact use case. It won't wander off-topic. It will speak in your company's voice. It will apply your business logic without you having to re-explain it in every conversation.

This is how every serious Claude deployment works. The system prompt is the product.

Claude reads system prompts carefully

Claude treats the system prompt differently from user messages. It carries more weight. If your system prompt says to respond only in Spanish, Claude will do that even if the user writes in English. If your system prompt defines specific behavior, it holds.

A few things that make system prompts work especially well with Claude:

XML tags help Claude organize instructions. If your prompt has multiple sections, wrapping them in named tags makes it easier for Claude to locate and apply the right piece.

Concrete beats abstract. "Be helpful" does less work than "When a user asks a question you can't answer, tell them what you can help with instead."

Examples are worth paragraphs. Show Claude one ideal response and you've communicated more than a full page of instructions.

The iteration loop

System prompts aren't set-and-forget. The best ones get built through testing — write a draft, run it against the questions your users actually ask, notice where Claude misses the mark, adjust.

Think of your system prompt as a living document. As your product evolves, your briefing should too.

---

Further reading

• Prompt engineering guide — Anthropic Docs