Three levels, each with a different sharing behavior:
| Level | Path | Shared via git? |
|---|---|---|
| User | ~/.claude/CLAUDE.md |
No — that user only |
| Project | root CLAUDE.md or .claude/CLAUDE.md |
Yes |
| Directory | CLAUDE.md in a subdirectory |
Yes, scoped to that subtree |
Not a strict override chain — each level answers a different question: who should see this, and how broadly it applies.
Working through why a convention isn't loading is common enough in this domain to have its own repeatable sequence — see ccar-m3-hierarchy-diagnosis-checklist.md for a step-by-step diagnostic to run before proposing a fix.
The discriminator, and it resolves most of this task statement on its own: user-level configuration is not version-controlled, so teammates never receive it. The single most repeated scenario shape here is a new team member whose Claude ignores conventions that "work for everyone else" — because those conventions live in an existing member's ~/.claude/CLAUDE.md, not in anything git ever shared. The fix is moving them to a project-level CLAUDE.md committed to the repo, not asking the new member to copy a file locally (works once, drifts immediately) or documenting the conventions in a README (never loads into context at all).
Two tools for keeping a large CLAUDE.md from becoming an unmanageable monolith:
@importreferences pull in external files — each package or area importing only the standards files its own maintainers actually need..claude/rules/organizes topic-specific rule files (testing.md,api-conventions.md,deployment.md) as a structural alternative to one giant document.
/memory shows which memory files are actually loaded in the current session. This is the first diagnostic step whenever behavior is inconsistent across sessions or across teammates — run it before theorizing about causes, because it directly answers "is the file I think is loaded actually loaded."