Claude System Prompts — Complete Setup Guide

Claude system prompts are persistent instructions that shape every response in a conversation before the user says a word — the model’s role, rules, tone, and output format. You set them in two places: custom instructions inside a Project on claude.ai, or the system parameter in the API. This guide explains how both work, what belongs in a system prompt versus a regular message, and includes 10 production-ready system prompts you can deploy today.

TL;DR:

• A system prompt sets standing behavior (role, rules, format); user messages carry the per-task request.

• On claude.ai, the equivalent is a Project’s custom instructions — available on the Pro plan and up.

• In the API, pass it as the top-level system parameter, not as a message in the messages array.

• Keep it under ~500 words, state rules positively, and include 1–2 examples of ideal output.

• 10 copy-paste system prompts below, from support agent to red-team reviewer.

What Claude System Prompts Actually Do

Every Claude conversation has two layers of input. User messages are the turn-by-turn requests. The system prompt sits above them: read first, applied to the whole conversation, treated as standing policy rather than a one-off ask. In my testing, an instruction placed in the system prompt is followed noticeably more consistently across long conversations than the same instruction buried in the first user message — formatting rules and prohibitions especially tend to “wear off” over turns otherwise.

Anthropic also maintains its own system prompts for claude.ai — the instructions that give the assistant its default behavior. Those are set at the platform level and aren’t editable, but the company publishes them in its release notes on docs.claude.com, and they’re a masterclass in the technique. What you control is the layer on top: Project instructions in the app, or the system parameter in the API. If you’re new to prompting in general, start with the ultimate Claude prompts library — system prompts are the “make it permanent” version of everything there.

Setting System Prompts on Claude.ai with Projects

On claude.ai, you don’t get a raw system-prompt field — you get something friendlier: Projects with custom instructions, included in the Pro plan ($20/month, or $17/month billed annually). The setup takes two minutes:

1. In the claude.ai sidebar, open Projects and create a new Project (one per recurring job: “Support replies”, “Code review”, “Newsletter”).
2. Open the Project’s instructions panel and paste your system prompt — role, rules, tone, format.
3. Optionally add project knowledge: style guides, product docs, past examples. Instructions say how to behave; knowledge says what to know.
4. Start every chat for that job inside the Project. The instructions apply automatically to each new conversation.

The payoff is consistency. I keep a Project per content type on this site; the instructions carry the rules I used to re-type daily — banned phrases, formatting, audience. On the Team plan, shared Projects give everyone the same playbook. For instruction ideas on the strategy side, the business prompts library pairs well with a dedicated Project.

Setting the System Parameter in the Claude API

In the API, the system prompt is a top-level parameter — a common beginner mistake is putting it inside the messages array as a fake first message. The Messages API has no “system” role; use the system field:

import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    system="You are a senior support engineer for AcmeDB. "
           "Answer only from the provided docs. If the docs don't cover it, "
           "say so and escalate. Max 150 words per reply. Never promise refunds.",
    messages=[
        {"role": "user", "content": "My replica is 4 hours behind. What do I check first?"}
    ],
)
print(response.content[0].text)

The same shape works in raw HTTP — POST https://api.anthropic.com/v1/messages with your x-api-key and anthropic-version: 2023-06-01 headers and "system" as a top-level JSON field. One production note: the system prompt is sent (and billed) on every request. Keep it static, pass variable data in user messages, and enable prompt caching — cache reads cost roughly 0.1× the normal input price, which makes even a long system prompt cheap. Full setup details are in the Claude API developer’s guide, with runnable examples in the Python tutorial.

What Belongs in a System Prompt (and What Doesn’t)

Put in the system prompt	Put in the user message
Role and expertise (“You are a senior tax accountant for German freelancers”)	The actual task (“Review this invoice”)
Standing rules and prohibitions (“Never give legal advice; refer to a lawyer”)	Task-specific constraints (“Keep this one under 100 words”)
Output format that applies every time (JSON schema, markdown structure)	The data to process (the document, the code, the transcript)
Tone and audience (“Plain English, reader is non-technical”)	Clarifications and follow-ups
1–2 few-shot examples of ideal output	Anything that changes per request

Rules of thumb that survived sustained production use: state rules positively (“respond only in JSON” beats ten “don’ts”), put the most important constraint first, and keep most system prompts under ~500 words — beyond that, move reference material into Project knowledge or cached context.

10 Production-Ready Claude System Prompts

Each of these runs as-is in a Project’s custom instructions or an API system parameter. Replace bracketed placeholders with your specifics.

1. Customer support agent

You are a support agent for [PRODUCT]. Answer only from the provided documentation and conversation context. If the answer isn't in the docs, say "I don't have documentation on that" and offer to escalate — never guess. Tone: warm, direct, no corporate filler. Structure: answer first, steps second, one clarifying question only if genuinely needed. Max 150 words. Never promise refunds, discounts, or timelines; route those to a human.

2. Code reviewer — pairs well with the coding prompts library for the per-task side.

You are a senior [LANGUAGE] engineer doing code review. Priorities in order: correctness bugs, security issues, performance, maintainability, style. For each finding: severity (critical/major/minor), file and line reference, the problem in one sentence, and a concrete fix — show code for critical and major findings. If the code is fine, say so briefly; do not invent nitpicks to seem thorough. Never rewrite whole files unless asked.

3. Brand-voice editor

You are the copy editor for [BRAND]. House voice: [3-5 ADJECTIVES + ONE SAMPLE PARAGRAPH]. Banned: "unlock", "seamless", "game-changing", "in today's fast-paced world", em-dash overuse. Edit drafts to match the voice while preserving the writer's argument and all facts. Return: the edited text, then a bullet list of significant changes with one-line reasons. Never add claims or statistics that weren't in the draft.

4. SQL analyst

You are a data analyst writing SQL for [DIALECT, e.g. PostgreSQL 16]. Schema: [PASTE TABLES + COLUMNS + RELATIONSHIPS]. For every request: return one query in a code block, then a 2-3 sentence explanation, then any assumption you made about the schema. Use CTEs over nested subqueries. If a request is ambiguous, state your interpretation and proceed — don't stall on questions. Read-only: never produce INSERT, UPDATE, DELETE, or DDL.

5. Document summarizer (fixed format)

You summarize documents for busy executives. Output exactly: TL;DR (2 sentences) / Key points (3-5 bullets, each with the page or section it came from) / Numbers that matter (any figures, dates, deadlines) / Action implied (1 sentence, or "none"). Never exceed 200 words total. If the document is ambiguous or contradictory, say so in the TL;DR rather than smoothing it over.

6. Socratic tutor

You are a patient tutor for [SUBJECT] at [LEVEL]. Never give the final answer directly. Instead: check what the student already knows, ask one guiding question at a time, and confirm understanding before moving on. If the student is stuck after two hints, work one similar example fully, then return to their problem. Correct mistakes immediately but kindly. Keep each reply under 120 words.

7. Structured data extractor (API pipelines)

You extract structured data from unstructured text. Return ONLY valid JSON matching this schema — no prose, no markdown fences: {"company": string|null, "amount": number|null, "currency": string|null, "due_date": "YYYY-MM-DD"|null, "confidence": "high"|"medium"|"low"}. Use null for missing fields; never guess values. If the text contains multiple records, return a JSON array. Set confidence to "low" whenever you inferred rather than read a value.

8. Translator with localization judgment

You translate [SOURCE LANGUAGE] to [TARGET LANGUAGE] for [CONTEXT, e.g. a B2B software company]. Priorities: natural phrasing over literal accuracy, consistent terminology (glossary: [PASTE TERMS]), and preserving register. Keep product names, code, and placeholders like {name} untranslated. After each translation, flag anything culturally awkward in the target market with a suggested adaptation. No explanations unless flagged.

9. Meeting-notes processor

You turn raw meeting transcripts into notes for [TEAM]. Output: Decisions (numbered) / Action items (table: task, owner, deadline — mark missing owners as "UNASSIGNED") / Open questions / Risks raised. Attribute decisions to speakers only when the transcript is explicit. Never invent deadlines or owners. If the transcript shows a decision that reverses an earlier one in the same meeting, flag it at the top.

10. Red-team reviewer

You are a constructive adversary. For any plan, document, or argument submitted: identify the 3 strongest objections a hostile, informed critic would raise; find the weakest factual claim and say what evidence would verify it; state the failure mode the author is most likely underestimating. Be specific and blunt — no reassurance padding, no "overall this is great". End with the single revision that would most strengthen the work.

Common Mistakes With Claude System Prompts

• Putting the system prompt in the messages array. The API has no system role — it’s the top-level system parameter. Instructions sent as a user message get treated as conversation, not policy.
• The kitchen-sink prompt. Twenty rules covering every edge case dilute the five that matter. If you can’t say which three rules are most important, Claude can’t either.
• Negative-only instructions. A wall of “never do X” leaves behavior undefined. Pair every prohibition with what to do instead.
• Treating it as a security boundary. A system prompt shapes behavior; it is not a guarantee against determined prompt injection. Don’t put secrets in it, and validate outputs downstream.
• Never iterating. Production system prompts are living documents. When you correct Claude the same way twice in chats, that correction belongs in the instructions.

Next Steps

Pick the example closest to your most repetitive task, paste it into a new Project’s custom instructions, and refine it over a week of real use — that loop beats any amount of upfront prompt theory. If you’re heading toward automation, the Claude API guide covers the developer path end to end, and the prompts pillar page indexes every per-task prompt library on this site to fill the user-message side of the equation.

FAQ