Home › Study guides › CCAO-F › Domain 5 › Lesson 5.3

CCAO-F · Domain 5 · 12% of the exam · Lesson 5.3 · 20 min read

Writing effective system-level instructions

How to write standing instructions for Claude: which layer each rule belongs in, what to leave out, how to handle conflicts, and how to test before rollout.

Written against objective 5.3 of the official CCAO-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

5.3.1 Why a shared Project needs a standing brief

Rosa is an HR operations specialist at a home-goods retailer with 18 stores and about 400 employees. Every week the HR inbox fills with the same questions about holiday, expenses and shift swaps. The answers sit in three approved documents: the Leave Policy, the Expenses Policy and the Scheduling Policy. So Rosa sets up a shared Claude Project called Policy Helper, uploads the three policies and writes one line of instructions: "You are a friendly HR assistant."

Before sharing it, she asks a few questions the way a store colleague would. "Can I carry over my unused holiday?" gets a confident answer about typical carry-over limits that matches none of her documents and cites no section. "My manager cut my hours after I complained, is that legal?" gets two paragraphs of general employment law. Both are warm and fluent, and neither is safe for 400 people to act on.

Nothing is wrong with Claude here. The problem is who writes the prompt. A stockroom assistant reading on a phone between deliveries will not write a careful brief; they will type one line. Claude only knows what is in front of it. So everything that makes an answer safe has to be there BEFORE anyone types: which documents count, what to cite, and when to stop and send the question to HR. That is the job of system-level instructions: standing guidance, set once above the conversation, that Claude receives with every request in its scope.

That is harder than writing a prompt. You are briefing Claude for requests you will never see, from people who are not you, and you cannot patch the gaps one request at a time.

5.3.2 Four layers of standing instructions

Here is a question that trips people up. Rosa wants Claude to cite the policy section in every answer. Where does that rule go? Claude's apps offer several places for standing guidance, and each reaches a different slice of work. Too high, and a rule spills into work it was never meant for; too low, and it misses cases it should cover.

Think of the guidance a new employee in one of Rosa's stores receives. The company code of conduct applies wherever they work, and their personal habits travel with them. Their department's procedures apply at their post. A card at the returns counter explains one task, read only when that task comes up. The shift lead's morning briefing covers today. Claude's layers follow the same pattern.

Memorise the reach of each layer; the setting names (personal instructions currently appear as "Instructions for Claude") you only need to recognise. Rosa's citation rule belongs in the Project instructions: it holds for every chat in Policy Helper and means nothing elsewhere. The company's organisation instructions already tell Claude to keep customers' personal details out of responses. HR's skill for policy-change announcements loads in any chat where someone asks for one. Rosa's taste for bullet points sits in her personal instructions, where it affects only her.

The layers work together, so the risk is a clash. The Help Center documents one tie-break: when a personal instruction directly contradicts an organisation instruction, Claude favours the organisation's, though it warns that behaviour may vary in rare cases. Project instructions work alongside each person's own instructions, and Anthropic's guidance names no winner when those two clash. So Rosa plans for no clashes rather than relying on a winner. Only Owners can view the organisation instructions, so she asks the Owner what they say before writing her tone rules. And because every employee's personal instructions come with them into Policy Helper, she states the important rules explicitly, with their reasons.

5.3.3 What belongs in standing instructions, and what doesn't

A week after launch, a regional manager asks Rosa for a favour. The Riverside store was closed for a week after a flood, and its staff were allowed to swap shifts with other stores without the usual notice, for that week only. "Can you add that to Policy Helper so it knows?" It sounds helpful, and it is the classic way standing instructions go wrong.

Claude reads standing instructions with every request in their scope, so anything in them reads as true for every request. A one-week exception does not expire when the week does. Months later, a cashier at another store asks about swapping a shift and is told that notice may not be needed. The exception has leaked into work it was never meant for.

So give every line one test: is it true for every conversation in this scope, for as long as the instructions stand? If not, it belongs elsewhere. A one-off detail goes in the request that needs it: if Rosa drafts the notice to Riverside staff with Claude, the exception goes in that prompt. A dated fact the helper should know goes in a knowledge file that states its date. And a Riverside employee who asks Policy Helper is covered by the standing rule to route unclear cases to HR.

Reference text fails differently. The Leave Policy is true every time, but it is material, not instruction, and a copy pasted into the instructions drifts from the approved file the day the policy changes. The policies belong in the Project's knowledge; the instructions tell Claude how to use them.

What passes the test is guidance about HOW to work. The role says what the helper is for, and the audience says who asks and how they read. Tone and format set the defaults for every answer. Sources say which documents count and how to cite them. A when unsure rule says what to do when information is missing or documents disagree: ask, flag, or send the question to a person. Boundaries say what Claude must not do, with the reason. And review says which answers a person must check or approve before anyone acts on them. In Policy Helper, the policy says what is allowed, but the employee's manager still approves every request.

5.3.4 How to write instructions Claude can follow

Rosa's next draft is a list of don'ts: don't make things up, don't give legal advice, don't be rude. Every line is reasonable, and together they barely help. The habits of a good prompt apply here with more at stake, because nobody watches each conversation to catch a misreading. Five habits make the difference.

• Be specific. "Be professional" means something different to every reader, while "friendly and plain, answer first" can be checked. Anthropic's Claude 101 course warns that vague instructions lead to inconsistent results.
• Say what to do, and why. A target with a reason lets Claude apply the rule to cases you never listed, because, as Anthropic's prompting guide notes, Claude can generalise from the explanation.
• Say what to do when unsure. Anthropic's documentation lists three ways to reduce made-up answers, and all three fit here. Give Claude permission to say the documents don't cover something, tell it to answer only from the documents provided, and ask for a citation for each claim.
• Keep it short and organised. Group the rules under labels such as Role, Sources and When unsure, and state each rule once.
• Keep it consistent. Read the whole set before you save it. The Help Center warns that when instructions contradict each other, Claude may not follow either one reliably.

Here is Rosa's finished set. Look at the three lines that start with "When": they turn a missing detail, a gap in the documents and a conflict between them into visible questions and routes instead of guesses.

Role: You are Policy Helper. You answer questions from our store and head-office employees about leave, expenses and shift scheduling, using our approved policies.

Audience: most readers work in stores and read on a phone between tasks. Use short sentences and plain words, and answer the question in the first line.

Sources: answer only from the policy documents in this Project's knowledge. Name the document and section for every rule you state, for example "Leave Policy, section 4.2", because employees act on these answers and HR needs to see where each rule came from.

When an answer depends on details you don't have, such as contract type, store or dates, ask for them before answering.

When the documents don't cover the question, say so plainly and refer the employee to the HR Help Desk. Don't fill the gap from general knowledge, because other employers' rules often differ from ours.

When two documents disagree, don't choose one and don't combine them. Quote both sections, say that they differ, and refer the question to the HR Help Desk, which owns the policies.

For disputes, grievances, dismissal or legal rights, don't give legal advice or predict outcomes. Say which policy covers the topic, if one does, and refer the employee to the HR Help Desk for confidential help.

Describe what a policy allows; approving leave, swaps and expenses stays with the employee's manager, so never confirm an approval.

Tone and format: friendly and plain, like a helpful colleague. Give the answer, then the section reference, then any next step, in under 150 words unless the employee asks for more.

5.3.5 Test with awkward questions before rollout

Rosa's first test questions were ones she already knew the answers to: routine and well covered. Instructions almost never fail on easy questions. They fail on the question nobody planned for, and with 400 users that question arrives on the first morning.

Think of a fire drill: you find the blocked exit on a quiet afternoon, not during a fire. Testing works the same way, asking the awkward questions on purpose while a failure costs nothing. In practice, before sharing, run a small set of representative requests, including edge cases, each in a new chat, and compare every answer with a pass condition written in advance. The Help Center gives the same advice for organisation instructions: after saving, start a new conversation and try several kinds of question.

Memorise the four edge types: a missing detail, conflicting sources, a question outside scope, and a decision that belongs to a person. Rosa's conflict test failed on an early draft, before the set had its "When two documents disagree" line. The Leave Policy asks for four weeks' notice for holiday, the Scheduling Policy two weeks for any rota change, and Claude quietly chose four weeks. The employee would never have known that HR's own documents disagree.

So Rosa fixed the instructions, not the answer: she added the conflict rule with its reason, since a correction typed into the test chat would reach no other chat. Then she reran the whole set, because a fix for one case can disturb another, and every test passed.

5.3.6 The exam traps

Most traps in this objective put guidance in the wrong place, or leave Claude to decide something a person should.

• ✗ Adding a one-off exception or this week's detail to the standing instructions. ✓ Put it in the request that needs it. Standing instructions apply to every conversation in scope, so a temporary line leaks into unrelated work.
• ✗ Telling Claude to use the newest document, or to combine rules, when sources disagree. ✓ Answer from the approved documents and send unresolved conflicts to the policy owner. A file date is not approval, and a blend is a rule nobody wrote.
• ✗ Pasting the whole policy handbook into the instructions. ✓ Keep reference documents in the Project's knowledge and use the instructions to say how to use them. A pasted copy drifts from the approved file.
• ✗ Writing wishes such as "be accurate" or "be professional". ✓ Name the sources, the citation, the tone and the length. A wish adds no information Claude can act on.
• ✗ Putting a company-wide rule in one Project, or one workflow's rules in personal instructions. ✓ Match the layer to the reach: organisation for everyone, Project for one workflow, personal for you alone.
• ✗ Rolling out after testing only routine questions. ✓ Test awkward ones too: missing details, conflicting sources, out-of-scope requests and decisions for a person.

5.3.7 Put it together: write and test a standing brief

You now have every piece. Each rule sits in the layer whose reach matches it, only durable guidance stays in, and the rules are specific, explained and ready for awkward cases. The best way to see why each part matters is to take one away.

A standing brief is written once but has to stay true. Maintaining configurations (5.4) keeps the instructions and the knowledge they point to current: when a policy changes, when a temporary arrangement ends, or when a test that passed at launch starts failing months later. And when a Project starts giving poor answers, diagnosing poor outputs (7.1) checks these instruction layers among the places a problem can enter.

Key takeaways

• ✓ System-level instructions are standing guidance Claude receives with every request in their scope, so they must work for questions you will never see.
• ✓ Match the layer to the reach: organisation instructions for everyone, personal instructions for you, Project instructions for one workflow, skills for one kind of task.
• ✓ Standing instructions hold durable guidance: role, audience, tone and format, sources, what to do when unsure, boundaries and review steps.
• ✓ One-off details and exceptions go in the request and reference documents go in knowledge; anything temporary in the instructions leaks into unrelated work.
• ✓ Write rules that are specific, positive and explained, and send unresolved conflicts between sources to a person, never to the newest file.
• ✓ Test with routine and awkward questions in fresh chats before rollout, and fix failures in the instructions rather than in one chat.

Check your understanding

4 questions written for this lesson, then one from the CCAO-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• Understanding Claude's personalization features
• Set organization instructions
• What are skills?
• Introduction to projects (Claude 101)
• Prompting best practices
• Reduce hallucinations
• The CCAO-F exam guide, summarised