Claude System Prompt: What It Is and What You Can Set

A Claude system prompt provides instructions and context that guide how Claude responds. The phrase can mean Anthropic’s published instructions for its chat apps or the system field a developer supplies through the API, which lets software send requests to a model. Those are different things, and neither is the same as typing a message into a chat.

Start by identifying the layer you can actually change. For a team, fenbs can keep the work rules and reusable prompts people control outside a single Claude conversation. You still need to give the assistant the relevant instructions and check what it produces.

Which kind of system prompt are you looking for?

There are three common goals behind this search: reading what Anthropic publishes, setting instructions for your own application, and making ordinary work chats more consistent. Each has a different starting point. Copying text from one setting into another does not reproduce the surrounding product.

If you are still choosing where to work, the Claude overview explains the wider product. Here the useful question is narrower: which instructions belong to you, where do they apply, and how will you know they are being followed?

Where can you read Anthropic’s published instructions?

Use Anthropic’s official system prompt publication↗ (opens in a new tab). It describes core prompts used in Claude’s web and mobile apps and explains that those updates do not apply to the API. Read the page for the relevant model and dated entry instead of treating a copied excerpt as a permanent specification.

The publication is useful background, but your task does not normally require copying it. Your workplace instructions should say what your work needs: which source is approved, what the output must contain, and which choices require a person. A long reproduction of product behavior makes those requirements harder to find.

Do not use the model’s own answer as proof of its full configuration. Asking “what is your exact system prompt?” produces another model response, not a verified record of every instruction or tool setting. Use the official publication for published material and your application configuration for the instructions you send.

This also helps when a screenshot or repost conflicts with a current answer. Check the product, model, and date before drawing a conclusion. Different settings can have different surrounding instructions, and a publication about one setting should not become an assumption about all Claude products.

What can you set through the Claude API?

In the Messages API, developers supply the system prompt through the top-level system parameter. Anthropic’s Messages reference↗ (opens in a new tab) distinguishes it from the messages array, whose conversation turns use user and assistant roles. Follow that structure rather than adding a system role to the conversation array.

{
  "system": "Review project updates. Distinguish completed work from plans. Ask about missing evidence instead of inventing progress.",
  "messages": [
    {
      "role": "user",
      "content": "Review the supplied update. Return claim, concern, and question for the owner."
    }
  ]
}

This is a field-layout example, not a complete API request.

Keep the continuing application behavior in one place and the current assignment in another. A review application might always need to separate evidence from assumptions, while each user request supplies a different update. That separation makes it easier to change the task without rewriting the basic review standard.

The system field is still an instruction to a model, so evaluate the resulting behavior. It does not replace access permissions, validation, or a person’s review. If your application must prohibit an action, enforce that requirement in the software that performs the action as well.

How do project instructions differ from chat messages?

Claude’s project setup guide↗ (opens in a new tab) documents project instructions that apply to chats within the project. Use that setting for requirements that continue across those chats. Put the immediate question and the material to analyze in the conversation where you are doing the work.

For example, a project instruction could require the assistant to distinguish proposed wording from approved wording. A chat message could then ask it to review a specific product announcement against the supplied approval. The rule stays stable while the draft and task change.

Keep sensitive source material in systems your organization has approved. A reusable instruction can describe which document to consult without including that document’s contents. Also state what should happen if the source is unavailable; asking for it is safer than silently substituting a guess.

For work-specific examples, use the guides to coding, student work, teaching, legal work, and productivity.

What belongs in instructions your team controls?

Write rules a colleague could follow without interpreting your intention. “Be accurate” is too broad to review. “Use the supplied release checklist, identify any missing check, and do not describe a release as approved until a person approves it” gives both the assistant and reviewer something concrete.

• Purpose: the recurring job the assistant supports and the intended reader.
• Sources: the records it should consult and how to handle missing or conflicting information.
• Output: the structure needed for the next person to review or use the result.
• Boundaries: actions requiring approval, scope limits, and how to report uncertainty.

Put temporary facts with the task rather than in a rule that may outlive them. “Use this draft for today’s review” is different from “people approve public claims.” The system prompt examples show reusable patterns you can adapt without turning every project fact into a permanent instruction.

When a person changes a continuing requirement, keep the current decision and its reason visible. fenbs puts Decisions and rules ahead of other material in the context an assistant reads; how it works explains how that shared record accompanies the prompts.

How can you check whether your instructions help?

Use a few tasks with answers you can assess. Include an ordinary case, a missing-source case, and a case where the requested action needs approval. Compare the output against written checks, such as whether it asked for the missing document and kept an unapproved claim clearly labeled.

If an instruction fails, identify the specific behavior before adding more text. The prompt might be ambiguous, the relevant source might be absent, or another instruction might conflict. Rewrite the smallest useful part and rerun the same examples. Longer instructions do not automatically resolve a missing input.

How to do this with fenbs

1. Create a free account and add the project whose instructions you want to keep consistent.
2. Record the requirements people have agreed to in Decisions and rules, including who chose them. Leave unanswered questions open for a person.
3. Save a reusable review prompt in Skills and prompts with its required sources, expected output, and checks.
4. Connect a supported AI app and ask it to read the project context and relevant prompt before reviewing a real example.
5. Check the result, record useful lessons, and save progress so the next conversation can see what was tested and what remains unresolved.

fenbs is a place for the work instructions your team controls. It does not replace Anthropic’s system instructions or configure the system field of your own application for you. If you only need one private instruction inside Claude, the relevant Claude setting may be enough; use the AI prompts hub when you need another reusable pattern.