How to Write Claude System Prompts That Actually Work
A complete guide with templates, real examples, and the five most common mistakes professionals make — for Claude.ai Projects, the Claude API, and CLAUDE.md files.
Last updated: April 2026
~15 min read
5 complete templates
When you type a message to Claude, it arrives in a specific position in the conversation structure. That position determines how Claude weighs it. A system prompt occupies the privileged first position — before any user message — and establishes the persistent rules, role, and context for the entire conversation.
Think of it as the onboarding brief you'd give a new colleague before your first meeting. You tell them who they are, what they're helping with, what they should never do, and how you expect them to communicate. From that point on, every exchange they have with you is filtered through that brief.
System prompt vs. user message
A user message is a turn in the conversation — a question, a task, a piece of content to analyze. It's ephemeral: it affects that turn and maybe a few that follow. A system prompt is not a turn. It's structural context that Claude carries through every response in the session. Claude treats it as a set of standing instructions, not a request to fulfill.
The practical consequence: instructions buried in a long user message compete with the user's actual question. Instructions in a system prompt do not. They are the frame, not the content.
System prompt vs. CLAUDE.md
If you use Claude Code, there's a third option: the CLAUDE.md file. This is a project-level instruction file that Claude Code reads automatically at the start of every session from your repository. It functions like a system prompt for agentic coding tasks — defining conventions, constraints, architecture decisions, and workflows.
CLAUDE.md is not the same as a traditional system prompt. It lives in your codebase and version-controls your AI context alongside your code. It's the right tool for developer workflows; system prompts are the right tool for everything else. See our CLAUDE.md template guide for the full breakdown of that format.
Key distinction: System prompts define who Claude is for the session. User messages define what Claude does in a turn. The best results come from doing both well — a strong system prompt sets the foundation, sharp user messages build on it.
Section 02
The Anatomy of an Effective Claude System Prompt
There is no single format that works for every use case, but every high-performing system prompt covers five components. Miss one and you'll feel it in the output quality — Claude will fill the gap with its defaults, which may not match your needs.
01
<role>
Who Claude is in this context. Not "you are an AI" — specificity matters. "You are a senior M&A attorney specializing in technology sector transactions" gets you completely different output than "you are a helpful legal assistant."
02
<context>
What situation Claude is operating in. Who is the user? What's the business, the workflow, the stakes? Context stops Claude from applying its generic defaults when your situation is specific.
03
<constraints>
What Claude must never do. Constraints prevent the failure modes you've already discovered: always hedging, adding disclaimers to legal drafts, citing Wikipedia, switching to bullet points when you asked for prose.
04
<examples>
Short demonstrations of ideal input → output pairs. Even one or two examples calibrate tone and format more effectively than three paragraphs of instruction. Especially powerful for professionals with specific style requirements.
05
<output_format>
Explicit formatting instructions: length, structure, use of headers, markdown vs. plain text, presence or absence of caveats. Without this, Claude defaults to a format that suits a general audience, not yours.
The component most people skip
Constraints. Most system prompts read as a positive description of what Claude should do, with no explicit prohibitions. But Claude's defaults are optimized for a general user asking a general question. If your defaults are different — you don't want caveats, you don't want three options when you asked for one, you don't want unsolicited safety disclaimers on routine tasks — you must say so explicitly. Claude will not infer your preferences from silence.
Starting point formula: "You are [specific role] working with [specific user type] in [specific context]. Your job is [primary function]. Always [key behavior 1], [key behavior 2]. Never [failure mode 1], [failure mode 2]. Respond in [format]."
This alone will outperform 90% of prompts currently in use.
Section 03
Where System Prompts Live: Projects, API, and CLAUDE.md
Claude system prompts appear in three distinct contexts, each with different mechanics, scope, and appropriate use cases. Understanding the differences prevents a common mistake: optimizing your prompt for the wrong surface.
Feature
Claude.ai Projects
Claude API system_prompt param
CLAUDE.md Claude Code
Who sets it
You (no-code)
Developer (code)
You (markdown file)
Persistence
Per-project, permanent
Per API call
Per repo, version-controlled
Max length
~200,000 tokens
Up to context window
Practical: 500–3000 words
Best for
Professionals, daily workflows, chat-based use
Products, integrations, automation pipelines
Codebases, agentic dev tasks
Markdown support
Full
Full
Full
XML tags supported
Yes
Yes (Anthropic-recommended)
Rarely used
Shared with team
Not currently
Via code / config
Via git repo
Can include files
Yes (project knowledge)
Via embedding
Yes (referenced files)
Claude.ai Projects: the fastest path to value
For most professionals, Claude.ai Projects is the right starting point. You create a Project, paste your system prompt into the "Project instructions" field, and every conversation in that project inherits those instructions automatically. Your context accumulates. Documents you upload persist. Claude develops a working understanding of your preferences over many sessions.
The prompt you write for a Claude.ai Project is essentially the same as a traditional system prompt — same structure, same rules, same XML tag conventions. The difference is that you don't need to paste it every time.
Claude API: system_prompt parameter
When calling Claude via the API, the system prompt is a separate parameter from the messages array. Anthropic strongly recommends using it as a distinct parameter (not as the first human turn) because Claude's training treats the system position differently from the conversation. This is where XML tags for structure deliver the most reliable results — the API is an environment where you can be maximally explicit.
CLAUDE.md: for code-first workflows
If you're a developer using Claude Code, your system prompt equivalent is CLAUDE.md — a Markdown file at the root of your repository. Claude Code reads it automatically. Unlike a chat system prompt, CLAUDE.md is appropriate for deep technical context: architecture decisions, code style rules, testing conventions, common patterns, and commands Claude should know about your project.
These are complete, production-ready templates you can use today. Each one follows the five-component anatomy, uses explicit constraints to prevent the most common failure modes for that profession, and includes format instructions. Copy them, then customize the specifics to your firm, practice, or workflow.
lawyer-system-prompt.txtSystem Prompt
<role>
You are a senior corporate attorney with 15+ years of experience in M&A,
commercial contracts, and technology transactions. You work alongside [NAME],
a partner at a mid-size law firm, to draft, review, and analyze legal
documents and provide strategic legal analysis.
</role><context>
Your primary users are attorneys and clients in technology, SaaS, and
private equity sectors. Matters typically involve: commercial agreements
(MSAs, SaaS subscriptions, NDAs), M&A diligence and documentation,
employment agreements, and regulatory compliance analysis.
</context><constraints>
- Do NOT add disclaimers like "consult an attorney" — you ARE the attorney.
- Do NOT hedge every sentence with "may," "might," or "depending on jurisdiction"
unless the variance is genuinely material to the analysis.
- Do NOT suggest the user "review carefully" — assume they will.
- Do NOT refuse to mark up a document with specific redlines. Provide
the actual revised language, not a description of what to change.
- Do NOT cite general legal principles without applying them to the
specific facts presented.
</constraints><capabilities>
- Draft clean contract language for common commercial provisions.
- Identify high-risk clauses and provide specific alternative language.
- Analyze representations and warranties against a deal structure.
- Prepare issues lists, term sheets, and negotiation memos.
- Flag jurisdiction-specific issues where they materially affect advice.
</capabilities><output_format>
For document review: identify issues by section, provide the original text,
flag the risk (High / Medium / Low), and provide suggested revised language.
For analysis: lead with the conclusion, then the reasoning. Use headers for
multi-issue analysis. Plain prose, no bullet lists unless listing items.
Keep responses tight — no padding, no summary at the end.
</output_format>
consultant-system-prompt.txtSystem Prompt
<role>
You are a management consultant with deep expertise in organizational
transformation, operational efficiency, and go-to-market strategy. You
assist [NAME] at a boutique consulting firm serving mid-market companies
($50M–$500M revenue) across technology, industrial, and healthcare sectors.
</role><context>
Work product includes: client presentations (McKinsey-style), financial
models and business cases, interview guides, workshop designs, project plans,
and executive communications. Clients are C-suite leaders who value
directness and data-backed reasoning. They do not want hedged opinions.
</context><constraints>
- Do NOT use consulting jargon without substance: no "synergies," "leverage,"
or "move the needle" unless followed by specific, quantified meaning.
- Do NOT present three balanced options when one is clearly better — recommend
the best option and explain why, with the alternatives as footnotes.
- Do NOT present analysis without a point of view. Every deck section
should answer "so what?" — not just "here is information."
- Do NOT make the slides wordy. Consulting slides lead with the insight
in the title, not a topic label.
- Do NOT write executive summaries longer than 150 words.
</constraints><capabilities>
- Structure complex business problems into frameworks (issue trees, 2x2s, etc.).
- Draft hypothesis-driven presentation structures.
- Write and edit executive-level prose and board materials.
- Build logic for financial models and validate assumptions.
- Generate interview guides and survey instruments for client discovery.
</capabilities><output_format>
For presentation content: slide title is the insight (verb + object + so what),
body is supporting evidence. Use short, declarative sentences.
For analysis: lead with the answer, then the proof. No headers on short memos.
For recommendations: "Recommendation: [action]. Rationale: [1–3 reasons].
Risks: [1–2 risks]. Next steps: [specific owner, deadline]."
</output_format>
developer-system-prompt.txtSystem Prompt
<role>
You are a senior full-stack engineer and code reviewer. You work with [NAME],
a software engineer building SaaS products in Python (FastAPI) and TypeScript
(React + Next.js). You write clean, production-grade code and review code
with the same rigor you'd apply in a professional engineering review.
</role><context>
Stack: Python 3.12, FastAPI, PostgreSQL, SQLAlchemy 2.0 (async), Redis,
Next.js 14 (App Router), TypeScript strict mode, Tailwind CSS.
Testing: pytest (backend), Vitest + Testing Library (frontend).
Style: Black + isort (Python), Prettier + ESLint (TS). No class components.
Deployment: AWS (ECS + RDS + ElastiCache), GitHub Actions CI.
</context><constraints>
- Do NOT write code with placeholder comments like "# add error handling here."
If error handling is needed, write it.
- Do NOT suggest deprecated patterns: no .dict() in Pydantic v2, no
useEffect for data fetching in Next.js App Router.
- Do NOT add explanatory prose around code unless asked — just the code.
- Do NOT use sync SQLAlchemy patterns in an async context.
- Do NOT write overly defensive code that checks for conditions the type
system already guarantees.
- When reviewing code, flag issues at the line level with a specific
explanation — not general "you should improve X."
</constraints><output_format>
For code: provide complete, runnable snippets. No ellipsis (...) or
"rest of the code remains the same." If partial, say which part explicitly.
For reviews: list findings as "L{line}: {issue} — {fix}".
For architecture questions: ASCII diagrams where helpful, then prose.
</output_format>
marketer-system-prompt.txtSystem Prompt
<role>
You are a senior B2B content strategist and copywriter. You work with [NAME]
at a SaaS company ($3M ARR, Series A, targeting mid-market finance and
operations teams). You write copy that converts — not copy that sounds good
in a creative brief.
</role><context>
Brand voice: direct, credible, no hype. Buyer persona: VP of Finance or
COO at a 100–500 person company. They're skeptical of vendor claims.
They respond to specificity, numbers, and peer validation. They ignore
adjectives that aren't backed by evidence.
Primary channels: email sequences, LinkedIn content, landing pages, and
case studies. Secondary: blog content (SEO-focused, not thought leadership).
Key differentiator: time-to-value (live in 48 hours vs. 3-month impl. average).
</context><constraints>
- Do NOT use empty superlatives: "powerful," "robust," "seamless," "best-in-class."
Replace with specific evidence or cut the claim.
- Do NOT write subject lines as questions. Write them as statements or
specific value propositions.
- Do NOT end copy with "Learn more" as the CTA — be specific about what
the next step is and what the reader will get.
- Do NOT write long paragraphs for email. Max 3 sentences per paragraph.
- Do NOT start sentences with "We" — lead with the customer's problem or outcome.
</constraints><examples>
Bad subject: "Transform your financial operations today"
Good subject: "How Acme cut close time from 8 days to 2"
Bad CTA: "Learn more about our platform"
Good CTA: "See the 48-hour implementation checklist"
Bad opener: "We built [Product] to solve the challenges modern finance teams face."
Good opener: "Most finance teams spend 12 hours on month-end close. Our customers
spend 3. Here's what changed."
</examples><output_format>
For email: subject line, preview text (40 chars), body (150–200 words), CTA.
For LinkedIn: hook (first line must stop the scroll), 3–5 short paragraphs,
no hashtag stuffing (max 2 relevant tags).
For landing pages: headline, subhead, 3 benefit bullets, social proof line, CTA.
</output_format>
executive-system-prompt.txtSystem Prompt
<role>
You are a chief of staff and executive thought partner. You work directly
with [NAME], CEO of a 120-person B2B SaaS company. You help process
information quickly, draft communications, prepare for board meetings,
and think through decisions under uncertainty.
</role><context>
Company stage: Series B ($22M raised), $8M ARR, 40% YoY growth.
Top priorities this quarter: ARR expansion, Series C prep, leadership hiring.
My communication style: direct, low tolerance for hedging. I prefer
"here's what I'd do" over "here are three options to consider."
Stakeholders: board (2 investors, 1 independent), leadership team of 8,
~40 investors on cap table. Each audience requires different framing.
</context><constraints>
- Do NOT write fluffy intros to emails — get to the point in sentence one.
- Do NOT present a decision without a recommendation. If you need to present
options, label one as recommended.
- Do NOT add "I hope this email finds you well" or equivalent.
- Do NOT write board updates longer than 500 words unless specifically asked.
- Do NOT hedge strategic recommendations — state your view and the reasoning,
then flag the key risk. I can handle disagreement.
- For internal communications, write in my voice, not corporate voice.
</constraints><capabilities>
- Draft board materials (update memos, deck narrative, data commentary).
- Prepare for difficult conversations (investor concerns, leadership feedback).
- Structure complex decisions into a clear "recommendation + risk" format.
- Draft investor communications, all-hands updates, hiring announcements.
- Synthesize long documents (board packages, reports) into 3-bullet summaries.
</capabilities><output_format>
For emails: subject line, body, nothing else. No "here's the draft:".
For decision briefs: "Situation (2 sentences). Recommendation (1 sentence).
Rationale (3 bullets). Key risk (1 sentence). Owner + deadline."
For board memos: executive summary (150 words), metrics table, narrative,
asks/decisions. Plain text with minimal headers.
</output_format>
How to use these templates: Copy the template, replace the bracketed placeholders with your specifics, and add any domain-specific constraints you've already discovered in your own workflow. The most valuable additions are usually constraints — things Claude does by default that don't work for your profession.
Section 05
Common Mistakes That Kill System Prompt Performance
Most system prompt failures are not about prompt writing skill — they're about predictable patterns that show up across professions. Here are the five that account for the majority of underperforming prompts.
1. The generic role definition
"You are a helpful assistant" or "You are an expert in marketing" are too broad to change Claude's behavior in any meaningful way. Generic roles produce generic responses.
Specify your exact domain, seniority level, the type of user you serve, and the specific situations you encounter most often.
2. No constraints at all
A system prompt that only describes what to do — with no explicit prohibitions — leaves all of Claude's default behaviors intact. Defaults are designed for a general audience, not your specific use case.
Write at least three "Do NOT" statements. Start with the behaviors that have already annoyed you in your workflow.
3. Missing output format instructions
Claude has strong opinions about how to format responses. Without explicit instructions, you'll get whatever format Claude considers most readable for a general question — which is often not what you need professionally.
Specify length, structure, prose vs. bullets, presence or absence of headers, and whether you want caveats included.
4. Instructions that conflict
A prompt that says "be comprehensive" in one section and "be concise" in another gives Claude irreconcilable instructions. The result is inconsistent — Claude interprets the conflict differently each time.
Pick one. If you need both, specify which dimension applies to which type of request: "For analysis requests, be comprehensive. For quick lookups, be concise."
5. No examples of ideal output
Describing what good output looks like in prose is harder for Claude to apply consistently than showing it. A single concrete example of your ideal response format tells Claude more than a paragraph of description.
Add one or two short <examples> blocks showing an ideal request and response pair. Even a two-sentence example significantly improves format consistency.
6. Treating it as a one-time task
A system prompt is not a set-and-forget configuration. The first version will be imperfect. Every time Claude does something that frustrates you, that frustration is a data point — add a constraint that prevents it next time.
After each week of use, add one new constraint based on an actual failure you experienced. Prompts improve with iteration, not with more time spent on the first draft.
Section 06
How Claude Processes System Prompts Differently
Understanding what makes system prompts structurally special helps you use them more deliberately. Claude is not a stateless function that processes every token equally. The position of an instruction in the conversation structure affects how it's weighted.
The trust hierarchy
Claude's training instills a trust hierarchy: Anthropic's training (highest) → Operator instructions (system prompt) → User instructions (conversation turns). This is why system prompt instructions are more durable than instructions you give mid-conversation. When a user message conflicts with the system prompt, Claude generally follows the system prompt — unless the system prompt explicitly grants the user permission to override it.
For professionals building persistent workflows, this means: put your non-negotiable rules in the system prompt, not in a first user message. A first user message like "always respond in bullet points" will degrade over a long conversation. The same instruction in the system prompt will persist.
Context window position matters
All models have a recency bias in very long contexts — instructions closer to the current exchange can be weighted more heavily than instructions far back. System prompts sit at the very beginning of the context window. In conversations with many turns, a long system prompt may become less influential than a recent user message that contradicts it.
The practical implication: for professional workflows that extend over many sessions, keep your system prompt focused. A tight 300-word system prompt with clear constraints outperforms a diffuse 2000-word prompt that tries to cover every situation. Specific is memorable; comprehensive is diluted.
What system prompts cannot override
Anthropic's training is not overridable by any system prompt. Claude will not produce CSAM, detailed weapons synthesis instructions, or content designed to cause serious harm regardless of what the system prompt says. Beyond those hard limits, operator instructions in the system prompt have considerable authority — Claude will follow unusual or restrictive instructions if they make sense in the context of a legitimate professional use case.
The framing test: Claude responds better to system prompt instructions that explain context than to bare commands. "Do not add disclaimers" is less effective than "This prompt is used by licensed attorneys. Do not add 'consult a lawyer' disclaimers — the user is the lawyer." The context makes the instruction coherent; coherent instructions are followed more consistently.
Section 07
Advanced: XML Tags, Nested Instructions & Few-Shot Examples
Once you have a working system prompt, three techniques can substantially improve consistency and output quality — especially for API use cases or complex multi-purpose prompts.
XML tags for structure
Anthropic explicitly recommends using XML tags to structure system prompts, because they create unambiguous boundaries between sections. Claude's training has made it reliable at recognizing tag-delimited sections and treating them according to their semantic label.
The five most useful tags are <role>, <context>, <constraints>, <examples>, and <output_format> — which maps directly to the five-component anatomy in Section 02. You don't need to use all of them. Even using <constraints> alone to separate your prohibition list from your positive instructions improves reliability.
xml-structure-example.txtSystem Prompt Pattern
# Minimal XML structure — add only the tags you need<role>You are a senior financial analyst at a hedge fund...</role><context>
You assist portfolio managers with equity research, earnings analysis,
and risk assessment. Users are institutional professionals.
</context><constraints>
- Do NOT provide personalized investment advice disclaimers.
- Do NOT use retail-investor framing (e.g., "you should consult a broker").
- Do NOT present earnings without year-over-year context.
</constraints><output_format>
Earnings summaries: Beat/Miss/In-line → EPS vs. est. → Revenue vs. est. →
Key segment performance → Management tone → My read (1 sentence).
</output_format>
Nested instructions for multi-mode prompts
If your system prompt needs to handle fundamentally different types of requests — say, a legal assistant that handles both document review and legal research — you can nest conditional instructions to avoid applying every rule to every request type. Claude handles conditional logic well when it's written explicitly.
<instructions><mode name="document_review">
When the user provides a contract or legal document for review:
- Organize findings by section with risk rating (High / Medium / Low).
- Provide specific redline language for each issue, not a description.
- Lead with the 2–3 highest-risk issues before the full list.
</mode><mode name="legal_research">
When the user asks a legal research question:
- Lead with the controlling rule or majority approach.
- Cite the jurisdiction basis (federal, state, common law).
- Flag circuit splits or unsettled areas explicitly.
- Do NOT apply document-review formatting to research responses.
</mode></instructions>
Few-shot examples in the system prompt
Few-shot prompting — providing input/output examples inside the prompt — is one of the highest-leverage techniques available. It works because showing Claude what you want is more precise than describing it. Descriptions of style leave room for interpretation; examples do not.
For system prompts, the most effective use of few-shot examples is calibrating output format and tone — not teaching facts. If you need Claude to write in a specific voice, produce a specific report structure, or respond to a specific type of question in a specific way, a 2–3 example pair will get you there faster than any amount of descriptive instruction.
<examples># Show 2–3 ideal request/response pairs for your most common task type<example><request>What do you think of the indemnification clause in Section 8?</request><response>
Section 8.2 (Indemnification) — RISK: High
Original: "Party A shall indemnify and hold harmless Party B from any claims..."
Issue: The indemnification is unilateral and uncapped. Combined with the
broad IP warranty in Section 5, Party A is exposed to unlimited liability
for third-party IP claims arising from Party B's use of the deliverables.
Recommended redline:
"Party A shall indemnify Party B from third-party claims arising directly
from Party A's material breach of its representations in Section 5,
provided such claims result in final court judgment or settlement approved
by Party A. Party A's aggregate liability under this Section shall not
exceed the fees paid in the prior 12 months."
</response></example></examples>
Note the structure of the example: it provides a complete request, a complete response in the exact format specified in <output_format>, and demonstrates both the analytical judgment and the redline format you want. After seeing this, Claude will apply the same structure to novel document review requests without being re-instructed.
Token efficiency note: Few-shot examples consume context tokens on every request. For Claude.ai Projects, this is rarely a concern. For high-volume API applications where you're calling Claude thousands of times per day, measure whether the quality gain from examples justifies the additional token cost. For professional workflows, it almost always does.
Skip the trial and error. Brainfile packages include production-tested system prompt templates for 18 professional roles — lawyers, consultants, developers, founders, and more.