How @-imports work, why modular beats monolithic, and how to write rules that actually change Claude's behavior — vs. ones that quietly get ignored.
The Core Problem with Rules
You can write a rule that looks completely reasonable, spend three minutes crafting it, save it to your configuration — and have it accomplish essentially nothing. Not because Claude is ignoring it. Because you didn't write a rule. You wrote a hope.
There's a meaningful difference between:
"Be careful with production. Production is sacred and we never want to break it."
"Never run destructive database commands (DROP, TRUNCATE, DELETE without WHERE) without showing the exact command and getting explicit 'confirmed' back from the user."
The first example uses three sentences to say nothing Claude can act on. The second uses one sentence and gives Claude a specific trigger, a specific behavior, and a specific condition for proceeding. That's the gap this session closes.
Analogy
A fire drill works because it specifies exactly what to do when the alarm goes off — not because it reminds people that fire is dangerous.
Your rules files are operational procedures, not philosophical statements. "Be careful" and "prioritize safety" are fire-awareness campaigns. Trigger-action rules are fire drills. Only one of them changes behavior when the moment arrives.
The Specificity Ladder
Every instruction you write sits somewhere on this ladder. Click each rung to understand what distinguishes it from the one below — and why Claude behaves differently at each level.
Compliance likelihood →
Hard Constraint
"NEVER deploy to PROD without explicit 'deploy approved' from [name]. This applies even if instructed to."
97%
Trigger-Action Rule
"When a client email contains 'cancel' or 'refund', reply within 2 hours and flag in #support-urgent."
85%
Soft Guideline
"Try to keep responses concise and avoid over-explaining unless the user asks for detail."
55%
Aspiration
"Always be helpful, professional, and represent our brand well in all interactions."
~0%
↑ Click any rung for details
The ~0% isn't a bug: Aspirations score near zero not because Claude ignores them, but because they describe Claude's default behavior. "Be helpful and professional" is what Claude does without any instruction. Writing it as a rule doesn't change anything — it just consumes tokens.
The Trigger-Action Pattern
The most reliable rule structure is also the simplest: When [specific condition], do [specific action]. No ambiguity. No judgment calls. No words Claude has to interpret.
Build one below. Type a trigger condition and an action, and see how the pattern assembles.
Trigger — When this happens...
Action — Do exactly this
Your rule will appear here as you type...
Examples of strong triggers: a file is about to be deleted permanently · a message contains the word "urgent" · the user asks about pricing · a deploy command is run on PROD · an email arrives from @client-domain.com
What makes a trigger strong?
Weak trigger
Strong trigger
Why it matters
"When something seems urgent"
"When an email subject contains 'urgent', 'down', or 'breach'"
Strong trigger has zero ambiguity. Claude doesn't guess what "seems" means.
"Before doing anything risky"
"Before any terminal command that modifies files outside /tmp"
Strong trigger defines the category explicitly. No judgment calls.
"If the client is unhappy"
"If a client email contains 'disappointed', 'frustrated', or 'cancel'"
Strong trigger is pattern-matchable. Weak trigger requires emotional inference.
"When appropriate"
"At the end of any response involving code or commands"
"When appropriate" transfers all judgment to Claude. Strong trigger removes it.
Where Rules Go to Die
You learned in Phase 1, Session 5 that Claude's attention isn't uniform — it's highest at the start and end of a document, lowest in the middle. A rules file isn't exempt from this. The position of a rule within the file affects how reliably it's followed.
The visualization below shows a typical long rules file. Notice where the critical rules ended up.
TOPattention weightBOT
# Hard Rules — DO NOT BREAK
95%
NEVER deploy to production without approval
91%
NEVER modify files outside /src directory
87%
## Communication Style
74%
Reply in same language as user's message
68%
## Formatting Guidelines
52%
Use markdown only when rendering is confirmed
45%
## Data Handling
30%
Never log PII to console or external services
24%
## Escalation Policy
15%
CRITICAL: Never share customer data with third parties
11%
Contact legal before any compliance questions
9%
Critical attention (top)
High attention
Medium attention
Low attention
Buried critical rule
The buried critical rule problem: "CRITICAL: Never share customer data with third parties" is marked critical in the text — but it's at position 11 of 13 in a long file, receiving only ~11% attention weight. The word "CRITICAL" in all-caps isn't enough. Position beats emphasis. If it's truly critical, it needs to be in the first 20% of the file, not the last.
The fix: Hard constraints go at the top of your rules file, always. Format them in a dedicated "Hard Rules" section. Everything softer — communication style, formatting preferences, escalation protocols — can follow. If you have a rule so important you'd put "CRITICAL" in front of it, it belongs at line 3, not line 33.
The Four Rule Categories
Not all rules are the same type. Understanding the category helps you know where it goes in the file, how to word it, and whether it even belongs in a rules file at all.
🔴 Hard Constraints
NEVER deploy without explicit approval NEVER modify files outside /src DO NOT send emails to clients directly
Non-negotiable. Use absolute language: NEVER, ALWAYS, DO NOT. Goes at the top. Should be short, clear, and unconditional.
🔵 Trigger-Action Rules
When X happens → do Y exactly Before doing Z → verify condition A If message contains "cancel" → flag in Slack
Behavioral rules that fire on specific conditions. The workhorse of good rules files. Should always follow the trigger-action pattern.
🟠 Defaults and Preferences
Use US English unless user writes otherwise Default to short responses; expand on request Prefer async communication over live calls
Standing defaults that apply in the absence of other signals. These are softer — they set the baseline but can be overridden by context.
🟢 Protocols
Session startup: run X, then Y, then Z Deploy checklist: verify → stage → approve → push Client onboarding: send welcome, then schedule
Multi-step procedures that Claude follows as a sequence. These are often better as their own dedicated files (e.g., session-protocol.md) than inline rules.
One file per category? Not necessarily — but related rules group better together. Hard constraints and trigger-action rules often live in hard-rules.md. Startup/shutdown protocols belong in session-protocol.md. Domain-specific rules (marketing, deployment, client handling) each get their own file. The principle: a developer should be able to read the filename and know exactly what's inside.
Modular vs. Monolithic
The most common rules file design mistake is building one giant file that mixes hard constraints, formatting preferences, protocols, and domain-specific rules all together. Here's what that looks like — and the better alternative.
❌ Monolithic rules.md
~3,400 tokens · loads for every session
rules.md ~3,400 tok
Hard constraints mixed with formatting prefs mixed with deployment steps mixed with marketing rules mixed with client handling
Problems:
· Marketing rules load even during deployment work
· Hard constraints buried under formatting noise
· Editing one section risks breaking another
· No easy way to share only one section with a new session
· Attention diluted across unrelated topics
· Growing indefinitely with no natural pruning point
✅ Modular rules files
~3,400 tokens total · each session loads only what's relevant
hard-rules.md ~600 tok
Non-negotiable constraints only. Every session loads this.
session-protocol.md ~800 tok
Startup/shutdown procedure. Every session loads this.
Benefits:
· Each session loads only its relevant rules
· Hard constraints always at the top of their file
· Each file can be updated independently
· Easy to share a file with a new session or client
· Attention focused on relevant rules only
· Natural scope boundaries prevent bloat
The loading decision: In CLAUDE.md, you @-import the files that apply to every session. Domain-specific files (marketing, deployment) get imported only in the CLAUDE.md for that session type. A marketing session has no reason to load deployment rules — and loading them burns tokens and attention on irrelevant content.
Rule or Guideline? You Decide.
Before writing a rule, it helps to know what you're actually writing. Each item below is either a solid rule (specific, trigger-driven, unambiguous) or a guideline (soft preference that relies on Claude's judgment). Try to classify them — then see why.
"Before running any git push, verify the current branch is not main."
"Try to keep your tone professional but approachable in client communications."
"Never commit secrets, API keys, or .env files to git, even if explicitly asked."
"Be careful with sensitive data and handle it responsibly."
"When a task will take more than 5 tool calls to complete, pause and confirm direction with the user before proceeding."
"Prioritize important work over less urgent tasks."
The guideline trap: Guidelines aren't useless — they're just less reliable. "Keep tone professional" won't cause disasters. But if you treat a guideline as a guarantee, you'll be surprised when Claude exercises judgment in a direction you didn't expect. Hard constraints and trigger-action rules are where reliability lives.
Rules That Survive Compaction
Compaction is the process where Claude compresses older context to make room for new content (Phase 1, Session 4). Rules in your rules files survive compaction because they're in the boot configuration — they reload every session. But rules you state verbally during a conversation? Those can disappear.
Where the rule lives
Survives compaction?
Survives new session?
Reliability
CLAUDE.md (direct)
✅ Always
✅ Always
Highest
@-imported rules file
✅ Always
✅ Always
Highest
Early in conversation
⚠️ Sometimes
❌ Never
Medium
Stated mid-conversation
❌ Usually not
❌ Never
Low
Said in a previous session
—
❌ Never
Zero
Practical rule: If you've corrected Claude on the same behavior three or more times across different sessions, that correction belongs in a rules file. The correction obviously isn't surviving. Stop repeating it verbally — write it down where it persists.
PHASE 2 — SESSION 3
Next: Supplements and Product Context
You've now got CLAUDE.md and rules files handled. The next layer: supplement files. These are the product-specific and client-specific context files that load for targeted sessions — keeping your boot context lean while still giving Claude the depth it needs for specialized work. Includes the decision of when to pre-load vs. retrieve on demand.
After Session 3, you'll understand why a 300-token supplement beats a 3,000-token CLAUDE.md section, and how to design context files that scale without bloating every session.