Create effective system-level instructions
Write system-level (project or account) instructions that are short, specific and testable: role, audience, output format, explicit criteria, and what to do when information is missing or a request would breach a constraint.
Key points
- 1
Instructions for Claude (account level) apply to all chats; project instructions apply only to chats within that Project. Use the project level for role- and task-specific guidance.
- 2
A good instruction names the role, the audience, the exact output format (for example user stories with Given/When/Then criteria, or a table with fixed columns), the style, and the rule for gaps: ask before assuming.
- 3
Replace vague adjectives ("be thorough, professional, accurate") with explicit criteria. Define a brand voice with named tone attributes, do/don't pairs, short example sentences and banned words rather than the label "brand voice".
- 4
Emphasis does not add information. "YOU MUST", capitals, repetition and "never make mistakes" do not change behaviour; a specification does.
- 5
For classification tasks, list the exact categories with a one-line definition and an example each, and add an explicit "unsure" route to a person. Do not instruct Claude to guess the most likely category when uncertain.
- 6
Give every absolute rule a branch for the missing case. "Always cite the SOW section" with no provision for uncovered topics pushes Claude to invent section numbers; "cite when a section supports the claim; otherwise say the SOW does not cover it and give no citation" does not.
- 7
Handle sensitive data on the input side as well as the output side: for example, replace any student name pasted into the chat with a placeholder and say so, rather than only forbidding names in outputs.
- 8
Keep instructions from growing by accretion. When they reach hundreds of words of overlapping rules, rewrite them as a short, prioritised set rather than appending more.
- 9
Reference material (style guides, handbooks, bank details, contracts) does not belong in instructions, and sensitive data the task does not need does not belong anywhere in the configuration.
- 10
Instructions should stop at the draft; do not instruct Claude to send, publish or write to external systems automatically when a person must review first.
- 11
Test instructions with a small saved set of prompts that cover the normal cases, the edge cases and the out-of-scope cases, and rerun it after every change.
- 12
Splitting audiences into separate Projects is a valid design only when the audiences are never needed in the same conversation; otherwise specify a format per audience in one instruction set.
Test yourself on Create effective system-level instructions
Ten questions, with the answer and explanation after each one.