CCAO-F 5.3 — Writing system-level instructions

The levels of standing instruction

broadest to narrowest

Organisation instructionsTeam and Enterprise owners; every conversation in the org
Instructions for Claudeyour account; all your conversations
Project instructionsevery chat inside one Project
Skillsloaded when a task calls for them
This chat’s promptthe task in front of you

Broadest at the top, narrowest at the bottom. Anthropic states that organisation instructions take precedence over an individual’s when the two conflict, and that personal instructions still apply wherever the organisation’s are silent.

The three standing levels, precisely

Organisation instructions are set by owners on Team and Enterprise plans, and Claude follows them in every conversation across the organisation. Anthropic documents a 3,000-character maximum and notes that a change can take up to an hour to propagate across Claude products. The example categories given are the sort of thing that genuinely applies to everyone: team identity and product naming, communication standards, response formatting, industry terminology, when to escalate or refer, and reminders about handling personal data.

Instructions for Claude sit at the account level and apply across your own conversations. They are set from the settings menu, and Anthropic’s guidance suggests they should carry your preferred approaches, the terms you use, the scenarios you commonly work in, and how you like to be communicated with. Project instructions, covered in 5.1, apply to every chat inside one Project. And Skills sit alongside all of these: rather than being always present, a skill is loaded when Claude judges it relevant to the task, which makes it the right home for a procedure rather than a standing preference.

Guide vs product · There is no “system prompt” box in the Claude apps

This task statement uses the phrase “system-level instructions”, which in the developer platform means the system prompt — a field you set in an API call. In the Claude apps there is no such field. The equivalents are organisation instructions, Instructions for Claude, and project instructions, which is what a scenario about a business user is describing. Answer app scenarios with those three; reserve “system prompt” for the API. Separately, Anthropic’s current personalization article presents Instructions for Claude, project instructions and Skills as the ways to shape Claude’s behaviour and does not describe custom styles, so if an older study aid tells you to set tone with a style, treat project instructions or Instructions for Claude as the safer answer.

Which level does this rule belong in?

Who and what does this rule apply to?

Everyone, always
Organisationnaming, escalation, data handling
All of my work
Instructions for Claudemy role, my terms, how I read
One body of work
Project instructionsaudience, sources, house style
A repeatable procedure
A skillloaded when the task arises

The test is how widely the rule is true. Put it one level too high and you irritate people; one level too low and you repeat yourself forever.

What makes a standing instruction actually work

The failure mode is not rudeness or length. It is vagueness. “Be professional”, “use our brand voice” and “be thorough” read like instructions and change almost nothing, because they give Claude no observable target. Anthropic’s prompting guidance offers a test worth applying to every line you write: show it to a colleague with minimal context on the task and ask them to follow it — if they would be confused, Claude will be too.

Four techniques from Anthropic’s documentation do most of the work. Set a role: the docs note that setting a role focuses Claude’s behaviour and tone, and that even a single sentence makes a difference. Explain why a rule exists, because Claude generalises from the explanation rather than pattern-matching the words — the documented example is that “never use ellipses” works better as “this will be read aloud by a text-to-speech engine, which cannot pronounce them”. Say what to do rather than what to avoid. And name the format you want, because current models follow instructions closely and will not infer a structure you did not ask for.

Weak line	Why it fails	Stronger line
“Be professional.”	No shared definition; every reader means something different	“Write in the second person, no exclamation marks, no jargon a new joiner would not know.”
“Don’t be too long.”	Negative and unmeasured; Claude cuts whatever it judges least important	“Lead with a two-sentence answer, then the detail under headings.”
“Use our terminology.”	Names nothing, so nothing changes	“Call the product Ledger Pro, never LP or the platform.”
“Be accurate.”	An aspiration, not an instruction	“Quote the clause you relied on; if the documents do not cover it, say so.”
“Ask if unsure.”	Claude cannot calibrate “unsure” without a threshold	“If a request needs data you do not have, ask for it before answering.”

Account-level instructions, rewritten

Changes nothingtext

I work in finance. Be professional,
accurate and concise. Use our
company terminology.

Changes most answerstext

I am a financial controller at a UK
manufacturer. Most of my work is month-
end reporting, variance analysis and
board packs.

Lead with the answer in two sentences,
then the working.

Show figures to two decimal places, in
GBP, and state the period they cover.
Board readers misread undated figures.

Recompute any arithmetic rather than
restating mine, and flag where we differ.

If a request needs data you do not have,
ask for it before answering.

The second version tells Claude who it is working with, what to do, why it matters and what to hand back. Every line is something you could check.

Worked example · Organisation instructions at a professional services firm

Priti is an owner on the Team plan at a 90-person consultancy. Client-facing documents keep going out with inconsistent product names, and twice this quarter a consultant has written something that should have gone through the risk team.

She resists the temptation to write everything down. The character budget is 3,000, and an instruction everyone has to live with should contain only what is true for everyone.
She writes four things: the firm’s name conventions; that client-facing writing is plain English with no jargon; that anything touching regulated advice must be referred to the risk team before it leaves the firm; and a reminder not to paste client personal data into chats.
She explains the reasons. The referral rule says why it exists, because a rule with a stated purpose generalises to cases she did not think of.
She leaves team specifics out. How the tax practice formats its memos belongs in that team’s Project, not in an instruction every consultant carries.
She tells people it exists, since staff who encounter unexplained behaviour assume something is broken.
She allows for propagation. Changes can take up to an hour to reach every Claude product, so she does not test the new wording thirty seconds after saving it.

Takeaway: Organisation instructions are the smallest tier and should stay that way. Their job is the handful of rules the firm would enforce regardless of who is asking or what they are working on.

Testing, and the conflicts you should expect

Standing instructions are configuration, and configuration is tested rather than assumed. The test is simple: take three real tasks that would previously have gone wrong in the way the instruction is meant to prevent, run them, and see whether the behaviour changed. If it did not, the usual cause is that the instruction described a quality rather than an action.

Conflicts are worth thinking about before they bite. Anthropic states that organisation instructions take precedence over individual user instructions when they conflict, while personal instructions continue to apply in areas the organisation’s instructions do not address. A conflict between your own levels — an account instruction that says “always be brief” against a Project that needs long formal memos — is not resolved by a documented rule so much as by you noticing the tension and narrowing the broader instruction. That is an argument for keeping account-level instructions to genuinely universal preferences.

Worked example · The instruction that quietly ruined every memo

Tom, a policy analyst, added “always answer in three bullet points, no preamble” to his Instructions for Claude after a week of over-long replies. A month later he cannot work out why his consultation responses keep arriving as fragments.

He finds the cause by elimination. New chats in every Project behave the same way, which points at an account-level setting rather than at any one Project.
He recognises the mistake. The rule was written for quick factual questions and applied to everything he does, including drafting that needs prose.
He narrows it. The account instruction becomes “for factual questions, answer in three bullet points; for drafting, write prose”.
He moves the rest to the right level. The consultation Project gets its own instruction covering register, length and structure for formal responses.
He re-tests on three real tasks — a quick lookup, a consultation draft and a briefing note — rather than assuming the fix worked.

Takeaway: An account-level instruction is carried into every piece of work you do. Anything that is not true of all your work belongs one level down, and the symptom of getting this wrong is behaviour you cannot trace to any particular conversation.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Writing instructions as qualities — professional, thorough, accurate	Write observable actions a colleague could follow without asking what you meant.
Putting team- or task-specific rules at organisation level	Keep organisation instructions to what is true for everyone; push the rest into Projects.
Writing rules as prohibitions	Say what to do instead, and give the reason so the rule generalises.
Expecting a personal instruction to override an organisation one	Organisation instructions take precedence in a conflict; personal ones fill the gaps.
Saving instructions and assuming they work	Re-run three real tasks that used to fail, and check the behaviour actually changed.

You should now be able to

Place a standing rule at the organisation, account, project or skill level according to its scope.
Rewrite vague instructions as observable actions with stated reasons.
Use role-setting, positive framing and explicit format requirements in standing instructions.
Explain how organisation and personal instructions interact when they conflict.
State the documented constraints on organisation instructions, including the character limit and propagation delay.
Test standing instructions against real tasks rather than assuming they took effect.

Writing system-level instructions