| Tier | Location | Who receives it | When it loads |
|---|
| Managed policy | System location, deployed by IT | Everyone in the org | Every session, cannot be excluded |
| User | ~/.claude/CLAUDE.md | Just you, all projects | Every session |
| Project | CLAUDE.md or .claude/CLAUDE.md | Whole team (committed) | Every session |
| Local | CLAUDE.local.md (gitignored) | Just you, this project | Every session |
| Subdirectory | CLAUDE.md deeper in the tree | Whoever works there | On demand, when Claude reads files there |
Loading: files concatenate, they never override. Broadest first, working directory last.
The one question: who needs to receive this decision?
| Surface | What it is | Use for |
|---|
| Memory files | Context that shapes judgment | Conventions, style, workflow preferences |
| Settings files | Enforced by the tool | Permission rules that must always hold |
| Hooks | Scripts at fixed session points | Checks the flow cannot skip |
Settings mirror the hierarchy: ~/.claude/settings.json (user), .claude/settings.json (project, committed), .claude/settings.local.json (personal, gitignored), managed (org, overrides all).
| Feature | Detail |
|---|
| Location | .claude/rules/, one topic per file, committed |
| Unscoped rule | Loads at launch, same priority as project memory |
| Scoped rule | paths frontmatter with glob patterns; loads with matching files |
| Personal tier | ~/.claude/rules/, loads before project rules |
| Size guidance | Target under 200 lines per memory file |
| Glob pattern | Matches |
|---|
**/*.ts | All TypeScript files anywhere |
src/**/* | Everything under src/ |
src/**/*.{ts,tsx} | Two extensions in one pattern |
| Scope | Location | Who receives it |
|---|
| Project | .claude/commands/name.md or .claude/skills/name/SKILL.md | Whole team, via the repo |
| Personal | ~/.claude/skills/name/SKILL.md | Just you, all projects |
Arguments: the $ARGUMENTS placeholder expands to whatever follows the command name.
Docs note: custom commands are merged into skills; existing command files keep working.
| Signal | Choose |
|---|
| Small, well-scoped, easy to revert | Direct execution, review the diff |
| Many files, unclear approach | Plan mode |
| Sensitive area (billing, auth, migrations) | Plan mode |
| Trivial edit with a failing test pointing at it | Direct execution |
| Mechanics | How |
|---|
| Toggle mid-session | Shift+Tab |
| Start a session in it | --permission-mode plan |
| Make it team policy | One line in project memory naming the risky paths |
| Step | Action |
|---|
| 1. Inventory | Run /memory on two machines, same repo; compare loaded files |
| 2. Sort by audience | Team decisions found at user level get promoted to project files, via PR |
| 3. Sort by force | Must-hold rules move out of memory into settings or hooks |
| Pitfall | Correction |
|---|
| Team decisions in personal config | If a new teammate needs it, it goes in the repo |
| Memory as enforcement | Prose is a request; settings and hooks guarantee |
| The 900-line memory file | Split into scoped rules and on-demand commands |
| Plan mode always or never | It is a per-change risk decision |
Spine applied: architecture is deciding where judgment lives; configuration is how those decisions become durable for a team.
