CC-301m · Module 1

Behavioral Anchoring in CLAUDE.md

4 min read

Instructions vary in their binding force. Some instructions shape behavior reliably. Others get processed and forgotten. The difference is not length — it is specificity, placement, and structure. Understanding what makes an instruction stick is what separates a CLAUDE.md that governs from one that decorates.

  1. Lead with behavioral defaults The first instructions read carry more weight than instructions buried in section 4. If your most important behavioral constraint — 'never commit without explicit confirmation' — appears after three sections of project overview, it will not anchor as strongly. Lead with the instructions that must hold unconditionally. Context and background come after behavior.
  2. Use imperative, not descriptive language "The project uses TypeScript strict mode" is a fact. "Run npx tsc --noEmit before considering any type change complete" is an instruction. Agents respond to imperatives. Descriptive sentences inform — they do not direct. Rewrite every behavioral intent as an explicit instruction.
  3. Name the failure mode you are preventing "Do not use git push --force" is an instruction. "Do not use git push --force — this overwrites upstream history and cannot be undone" is an instruction with a reason. When the reason is embedded in the instruction, the agent has context for edge cases the instruction does not explicitly address. Reason-bearing instructions generalize better.
  4. Use consistent signal words for priority "Must," "never," and "always" signal non-negotiable requirements. "Prefer," "typically," and "usually" signal defaults that can be overridden with good reason. Be consistent. If "must" sometimes means "strongly prefer," the agent cannot distinguish requirements from guidelines — and neither can you.
## Authorization Defaults

**Before taking any of the following actions, confirm with the user:**
- Committing changes to git
- Pushing to remote repositories
- Modifying CI/CD pipeline configuration
- Deleting files (not renaming — deletion)
- Installing or removing npm packages

**These actions are pre-authorized and do not require confirmation:**
- Running npx tsc --noEmit
- Reading any file in the repository
- Editing files when a change has been explicitly requested
- Running the test suite

**These actions are never authorized regardless of instructions:**
- git push --force to main or master
- Deleting the .env file or files containing API keys
- Modifying .github/workflows/ without explicit request