System Prompt Builder

Master the invisible instruction set that shapes every Claude conversation — with real code and anti-patterns

What Are System Prompts?

A system prompt is the invisible instruction set that defines who Claude is and how it behaves for a given conversation. It is sent with every API call but never shown to the end user. Think of it as hiring an expert and briefing them before they start work — the system prompt is that briefing.

A great system prompt has five key components: Identity, Constraints, Format, Tone, and Examples. Each serves a distinct purpose, and the order matters — Claude pays the most attention to content at the beginning of the system prompt.

Python — system prompt in the API

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system="You are a senior Python developer with 15 years of experience.\n\nRules:\n- Always include type hints in code examples\n- Explain reasoning before showing code\n- If the user's approach has issues, say so directly\n- Never use print() for debugging — suggest proper logging",
    messages=[
        {"role": "user", "content": "How should I handle database connections?"}
    ]
)
print(response.content[0].text)

The system parameter is separate from messages. It is sent once and persists across the entire conversation. User messages change; the system prompt stays constant.

The Five Components

Every effective system prompt is built from these five building blocks. You do not need all five for every use case — but understanding each one lets you craft the right prompt for any situation.

1. Identity — Who is Claude?

Defines the role, expertise, and persona. "You are a senior Python developer" or "You are a friendly writing tutor." This shapes the lens through which Claude approaches every response. Be specific — "a developer" is weaker than "a senior backend engineer who specializes in distributed systems."

2. Constraints — What must Claude NOT do?

Hard limits on behavior. "Never provide medical advice." "Keep responses under 200 words." "Do not speculate beyond the provided data." Constraints are your guardrails — they prevent Claude from drifting into territory you don't want.

3. Format — How should responses look?

"Always respond with: 1) Summary, 2) Detail, 3) Code example." "Use markdown." "Respond in JSON format." Format directives ensure consistent, parseable output — critical for production applications that need to parse Claude's response programmatically.

4. Tone — What voice should Claude use?

"Be encouraging and use analogies." "Be direct and technical — skip pleasantries." Tone shapes the personality without changing the content. The same technical answer feels different when delivered warmly vs. bluntly.

5. Examples — Show, don't tell

Include 1-3 input/output examples showing exactly what you want. Examples are the most powerful component — they disambiguate instructions that could be interpreted multiple ways. This is the "few-shot" technique from Lesson 6 applied inside a system prompt.

A Complete Production System Prompt

Here is a real-world system prompt that uses all five components. Notice how each section is clearly labeled with headers and ordered by priority:

Production system prompt — AI code reviewer

CODE_REVIEWER_PROMPT = (
    "# Identity\n"
    "You are a senior code reviewer for a production Python application.\n"
    "You have 10+ years of experience with Python, FastAPI, PostgreSQL,\n"
    "and distributed systems. You care deeply about code quality.\n\n"
    "# Constraints\n"
    "- NEVER approve code with SQL injection vulnerabilities\n"
    "- NEVER suggest quick hacks — always fix root causes\n"
    "- Do NOT review style (formatting, naming) — our linter handles that\n"
    "- If unsure about a security implication, flag it explicitly\n\n"
    "# Format\n"
    "Structure every review as:\n"
    "1. **Summary** — one sentence: what does this code do?\n"
    "2. **Issues** — numbered list, tagged [CRITICAL/WARNING/INFO]\n"
    "3. **Suggestions** — specific code changes, shown as diffs\n"
    "4. **Verdict** — APPROVE, REQUEST_CHANGES, or BLOCK\n\n"
    "# Tone\n"
    "Be direct and constructive. No sugar-coating, but no rudeness.\n"
    "Say what is wrong and how to fix it. Acknowledge good patterns."
)

This prompt produces structured, consistent code reviews with severity levels and clear verdicts. The headers make it easy to maintain and update — you can modify the Format section without touching Identity.

🔒

This lesson is for Pro members

Unlock all 520+ lessons across 52 courses with Academy Pro.

Go Pro — $49/mo ← Back to course

Already a member? Sign in to access your lessons.