Claude API System Prompt Examples for Common Use Cases

If you're searching for "Claude API system prompt examples," you're probably trying to figure out how to structure the system parameter to get consistent, on-brand, task-specific behavior out of Claude instead of generic chatbot answers. This article gives you working examples you can copy, adapt, and send directly in a request, along with the reasoning behind why each one is structured the way it is.

The short version: a good system prompt defines role, constraints, output format, and edge-case behavior — in that order. Everything below follows that structure so you can swap in your own domain details.

Why the System Prompt Matters More Than the User Message

In the Claude API, the system field is separate from the messages array. It's not just "extra context" — it's the highest-priority instruction Claude uses to interpret every subsequent turn. A weak system prompt ("You are a helpful assistant") produces generic output. A specific one produces predictable, production-ready output.

A basic request looks like this:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-3-5-sonnet-20241022",
    "max_tokens": 1024,
    "system": "You are a senior backend engineer reviewing pull requests. Point out bugs, security issues, and performance problems only. Do not comment on style or naming unless it causes a bug.",
    "messages": [{"role": "user", "content": "Review this function: ..."}]
  }'

Notice the pattern: role, scope, and an explicit exclusion. That exclusion is what prevents Claude from drowning real feedback in nitpicks.

Example 1: Customer Support Agent

You are a support agent for Acme Cloud Storage. You help customers with
billing, file recovery, and account access issues.

Rules:
- Only answer questions about Acme Cloud Storage products.
- If asked about a competitor or unrelated topic, say you can't help with that
  and redirect to support@acme.example.
- Never promise refunds. Escalate refund requests by saying you'll forward
  the case to billing.
- Keep responses under 150 words unless the user asks for more detail.
- Match the customer's tone: formal if they're formal, casual if they're casual.

This works because it gives Claude a decision tree for ambiguous cases (refunds, off-topic questions) instead of leaving them to improvisation.

Example 2: Structured Data Extraction

You extract structured data from unstructured text. Always respond with
valid JSON matching this schema, with no extra commentary before or after:

{
  "company": string,
  "amount": number,
  "currency": string,
  "due_date": string | null
}

If a field cannot be determined from the input, set it to null. Never
guess or fabricate values.

For extraction tasks, the explicit schema plus "never guess" instruction matters more than almost anything else in the prompt — it's the difference between a parseable API response and a model that helpfully invents a due date.

Example 3: Coding Assistant With Constraints

You are a pair-programming assistant for a TypeScript/Node.js codebase.

- Use async/await, not .then() chains.
- Assume Node 20+ and ES modules.
- Do not suggest external packages unless explicitly asked.
- When you return code, return the full function, not a diff or snippet
  with "// rest unchanged".
- If the requested change could introduce a breaking change to a public
  API, flag it explicitly before showing code.

Constraint-heavy system prompts like this prevent the most common frustration developers have with LLM coding help: inconsistent style and silently incomplete code.

Example 4: Tone and Persona Control

You are "Nova," the onboarding guide for a project management tool.
Voice: encouraging, concise, slightly informal. Use contractions. Avoid
corporate jargon like "synergy" or "leverage." Never use exclamation
points more than once per response. Address the user by first name if
it's provided in the conversation.

Persona prompts work best when they ban specific things rather than just describing a vibe. "Be friendly" is vague; "don't use exclamation points more than once" is enforceable.

Example 5: Multi-Step Reasoning Guardrails

You are a financial analysis assistant. Before giving a final answer:
1. State your assumptions explicitly.
2. Show the calculation.
3. Give the final number clearly labeled "Answer:".

If the user's input is missing data needed for the calculation, ask one
clarifying question instead of guessing.

This is useful anywhere correctness matters more than speed — financial, medical-adjacent (non-diagnostic), or legal-adjacent (non-advisory) contexts where you want the reasoning visible and auditable.

Putting This Into Production

Writing a good system prompt is only half the job — you also need somewhere reliable to send it from. If you're calling the Claude API directly from a backend, SubToAPI lets you turn your existing Claude access into a standard HTTPS API: you get an application key (sub_live_...), streaming support, tool use, and usage metadata per key, so each product or team using a given system prompt can be tracked separately.

const res = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-3-5-sonnet-20241022",
    max_tokens: 1024,
    system: "You are a support agent for Acme Cloud Storage...",
    messages: [{ role: "user", content: "I can't access my files" }]
  })
});

See the quickstart and messages docs for full request/response details, and pricing for plan options if you're running multiple system prompts across different products or teams.

Tips for Writing Your Own

• Lead with role, not personality. "You are a code reviewer" beats "You are friendly and helpful."
• Ban failure modes explicitly. If Claude tends to over-explain, add "no preamble, answer directly."
• Define the output format precisely if you're parsing the response programmatically.
• Test with adversarial inputs — off-topic questions, missing data, rude users — since that's where vague prompts break down.
• Keep it under a few hundred words. Long system prompts don't reliably improve adherence; specificity does.

FAQ

Does the system prompt count toward the token limit? Yes. System prompt tokens are counted as part of the input context, alongside the conversation history, so very long system prompts reduce the room left for conversation and output.

Can I change the system prompt mid-conversation? You can send a different system value on each request, but Claude doesn't retain memory of a system prompt across calls — you must include it (or an updated version) with every request in the conversation.

Should I put examples in the system prompt or in the messages array? Short behavioral rules belong in the system prompt. Longer few-shot examples of input/output pairs often work better as earlier turns in the messages array, since that format mirrors how the model processes conversation history.