Lesson 5.1
Custom Instructions and Project Instructions
The layers of standing instruction Claude follows, how they combine and conflict, and how to write instructions that make every conversation start from the right place.
Every message you send is read alongside instructions you set earlier: your personal preferences in settings, the instructions of the Project you are in, and the Style you have chosen. These standing instructions are how you stop repeating yourself and how a team gets consistent output. The exam tests where each layer lives, what belongs in each, and what happens when they disagree.
The layers
Anthropic's guidelines sit underneath everything. They define Claude's character and the Usage Policy boundaries, and no user instruction overrides them.
Personal preferences are set once in your profile settings and apply to every conversation you have, in or out of Projects. The settings include what Claude should call you, what kind of work you do, and a free-text field for preferences about how Claude should respond. This is the place for things that are true of you everywhere: your language variant, your default level of detail, your profession, formatting habits you always want.
Project instructions apply to every conversation inside one Project. They describe the work of that Project: role, audience, tone, format, rubric, what to refuse, how to use the knowledge. They are the most powerful layer for business use because they are specific.
Styles (next lesson) govern voice and formatting and can be switched per conversation.
The conversation itself is the final layer: whatever you say in the chat, with later messages generally taking precedence over earlier ones.
When layers conflict
Claude tries to honour all layers at once. Where they genuinely conflict, the more specific and more recent instruction usually wins: a Project instruction about tone will override a general personal preference, and a request in the chat will override both for that message. But "usually" is the operative word. Contradictory standing instructions produce inconsistent behaviour, and the fix is to remove the contradiction rather than to rely on precedence. If your personal preferences say "always be concise" and a Project needs detailed output, say so in the Project instructions explicitly: "Ignore any general preference for brevity; this Project requires full detail."
What belongs where
| Instruction | Layer |
|---|---|
| "Use British English. Call me Sam." | Personal preferences |
| "I am a procurement manager in the public sector." | Personal preferences |
| "Readers are non-technical executives; lead with the decision." | Project instructions |
| "Every figure must come from the attached pack." | Project instructions |
| "For this one reply, be blunt." | The conversation |
| "Write in our house voice." | A Style, referenced from Project instructions |
A useful test: would this instruction be wrong in some other context? If yes, it belongs in a Project, not in personal preferences.
Writing effective instructions
Good instructions resemble a good brief for a new team member who will do this job many times.
- Role and purpose. "You are helping the bids team draft responses to public tenders."
- Audience. Who reads the output and what they already know.
- Format defaults. Structure, length, headings, use of tables.
- Tone. Named, exemplified or linked to a Style.
- Rules. The must-haves and must-nots, stated plainly.
- Rubric. The criteria every output must meet, plus a self-check instruction.
- Handling uncertainty. "If the knowledge does not cover a point, say so rather than guessing."
- How to use the knowledge. Which document is authoritative for what; what to search for.
Keep it as short as it can be while covering those points. Instructions are read on every message, and a rambling instruction set dilutes its own effect. Prefer positive statements. Test by running three real tasks and watching for what the instructions failed to anticipate.
Before and after
A weak Project instruction:
Help with customer emails. Be professional.
A strong one:
You draft replies to customer support emails for a software company.
Readers are customers who are often frustrated; they want to know
what will happen and when.
Format: greeting using the customer's first name, one sentence
acknowledging the issue, numbered next steps with dates, a one-line
closing. Under 180 words.
Tone: calm, specific, no exclamation marks, no apologising more than
once. Match the examples in "Reply examples.pdf".
Rules: never promise a refund, credit or timeline not stated in the
ticket. Never mention internal team names. If the ticket lacks the
information needed to answer, draft a reply asking for it instead.
End each draft with a "Check" line listing any fact you assumed.
The second version makes every conversation in that Project start from the right place, and the "Check" line turns the output into something a reviewer can scan in seconds.
Maintaining instructions
Instructions drift out of date like any document. Assign an owner for each shared Project's instructions, revise when the process changes, and keep a short changelog in the instructions themselves (a dated line at the bottom) so colleagues know what changed. When a mistake recurs, the first question is "which instruction would have prevented this?"
Exam focus
- Layers run from Anthropic's guidelines, through personal preferences (everywhere), Project instructions (one Project), Styles (voice) to the conversation (latest message).
- More specific and more recent instructions generally take precedence, but contradictions cause inconsistency; remove them rather than rely on precedence.
- Personal preferences hold what is true of you everywhere; Project instructions hold what is true of a body of work.
- Effective instructions cover role, audience, format, tone, rules, rubric, uncertainty handling and how to use the knowledge, and stay as short as possible.
- A recurring error is a prompt to ask which instruction would have prevented it.
Check yourself
5 questions
1.A new user wants Claude to always use British spelling and address her by her first name, and separately wants a particular Project to always output in a client's report template. Where should each of these be configured?
2.A compliance team needs every document drafted in its 'Regulatory Responses' Project to end with a specific disclaimer and to avoid speculative language. Which configuration achieves this most reliably?
3.A Project's instructions say 'Always write formally.' In a chat inside that Project a user writes 'Make this version casual for the team Slack.' What should the user expect?
4.Which set of contents makes for effective Project instructions?
5.A team's Project instructions have grown to about 3,000 words of rules, reference facts and past examples. Claude now ignores some of the rules. What is the best diagnosis and fix?