Anthropic System Prompts: What You Can Learn From Them

"Anthropic system prompts" can mean two different things: the instructions Anthropic itself writes to shape how Claude behaves, or the system prompts that users and developers write when they deploy Claude for their own purposes. Understanding which is which makes a real difference to what you can actually control.

Anthropic publishes selected examples of its own instructions in its documentation and model cards. Those examples are worth reading because they show how a thoughtful team writes standing instructions for a large language model. Tools like fenbs can store the instructions you write for your own projects as reusable rules, so the reasoning behind each one stays alongside it.

Anthropic's own instructions vs yours

Anthropic trains Claude with values and guidelines baked into the model itself, then adds operator-level system instructions when Claude is deployed in a product. Those instructions set the persona, the scope, and the guardrails for that deployment. You cannot read or override them.

When you use Claude through the API or a third-party product, you may add your own system prompt. Your instructions sit in the operator or user tier, below Anthropic's own settings. Claude follows them within the bounds of its training and any operator constraints the deployment has set.

This layered structure is documented in Anthropic's usage policies and model card. The short version is: Anthropic's training and product-level settings come first, then an API operator's system prompt, then the user's instructions. A user-level system prompt cannot override what Anthropic has set at the training or operator level.

What Anthropic publishes

Anthropic has published selected system prompts and persona instructions for Claude products in its documentation and public model cards. These show how the team writes clear role definitions, handles ambiguous requests, and separates standing rules from contextual guidance.

Leaked or reverse-engineered versions of Claude's system prompt circulate online from time to time. Treat those with caution: they may be outdated, partially redacted or simply incorrect. For the facts about how Claude works, Anthropic's own documentation is the primary source.

What published examples reveal about prompt structure

Anthropic's published examples share several structural features that transfer well to prompts you write yourself.

• Role before rules: the prompt starts by defining what the assistant is and who it serves, before adding any specific constraints.
• Explicit handling of ambiguity: rather than leaving gaps, the instructions say what to do when a request is unclear or falls outside scope.
• Positive and negative instructions: the prompt says both what the assistant should do and what it should not do, rather than relying on the reader to infer the limits.
• Reasoning is sometimes visible: some published examples include a brief explanation of why a rule exists, which helps anyone reviewing or revising the prompt later.

These are not unique to Anthropic, but seeing them applied in a working prompt for a production AI makes the principles concrete. See system prompt examples for a set of examples you can adapt, and prompt engineering for a full guide to writing and testing AI instructions.

What you can control in your own system prompt

When you write your own system prompt for Claude through the API or an application that allows custom instructions, you control the role, the tone, the scope, and the constraints for that session. You can tell Claude what tasks to take on, what to decline, how to format its answers, and what to do when a request is ambiguous.

What you cannot control is Claude's underlying values, safety behavior, or the system-level instructions set by the operator of the product you are using. If you are using Claude through a third-party product rather than directly through the API, that product may have set its own constraints that your system prompt cannot override.

The distinction matters when you are debugging unexpected behavior. If Claude refuses a request even when your system prompt permits it, the refusal likely comes from a higher-level constraint, not from something you can fix in your own instructions.

Applying these lessons to your work

The most useful lesson from Anthropic's published examples is that good system prompts are specific and honest about their limits. They do not try to be comprehensive; they cover the cases that matter, handle the edge cases explicitly, and leave clear instructions for what to do when something falls outside the defined scope.

When you write system prompts for your own projects, record the reasoning behind each rule. "Always recommend the standard plan" is a rule; "Always recommend the standard plan because the accelerated plan has a history of scope creep" is a rule with a reason. A future assistant reading the record can apply the rule correctly even if the original context has been forgotten.

For the specific instructions that Claude's own system prompt uses, see Anthropic's published documentation at anthropic.com↗ (opens in a new tab) and the model card pages listed there. For what you can write yourself, see the article on the Claude system prompt.

How to do this with fenbs

1. Create a free account and add a project for the work you are using Claude for.
2. Write a system prompt using the structural lessons above: role first, then positive rules, then constraints, then the refusal case.
3. Test the prompt on your real inputs. Note any case where Claude's behavior does not match your instructions, and check whether the gap is in your prompt or in a higher-level constraint.
4. Add the tested prompt as a skill in fenbs. Record the reasoning behind any rule as a Decision.
5. Connect Claude over MCP from Integrations and ask it to read the skill at the start of each session.

fenbs keeps the instructions you write alongside the reasons behind them. When you need to update a rule, the record shows what you were trying to achieve, which makes the update faster and less likely to accidentally break a related constraint.