Lesson 3.1Lesson 13 of 30
CLAUDE.md hierarchy and modules
Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization
Key points
- 1Three levels: user ~/.claude/
CLAUDE.md(only you, all your projects), project ./CLAUDE.mdor ./.claude/CLAUDE.md(committed, whole team), directory-levelCLAUDE.mdin a subfolder (loaded when Claude works with files there). - 2The user-level file never reaches teammates or a CI runner through git. If a new hire or the pipeline "doesn't know" a team rule, look for it in someone's ~/.claude/
CLAUDE.mdand move it to the project file. - 3@path/to/file imports another file into
CLAUDE.md. Relative paths resolve from the importing file, and an @ inside a code span or block is not an import. Use it to pull in existing docs or only the standards a package needs. - 4Instead of one 1,000-line
CLAUDE.md, keep topic files in .claude/rules/ (testing.md,api.md,security.md). They are discovered automatically and are easier to own and review. - 5Behaviour differs between machines or sessions? Run /memory first: it lists the memory files actually loaded, so you compare facts, not guesses.
What the exam guide checks here
Objective wording from the exam guide (English).
- 3.1.K1Hierarchy: user ~/.claude/CLAUDE.md, project .claude/CLAUDE.md or root CLAUDE.md, directory-level CLAUDE.md
- 3.1.K2User-level instructions are not shared with teammates via version control
- 3.1.K3@import syntax keeps CLAUDE.md modular
- 3.1.K4.claude/rules/ holds topic-specific rule files instead of a monolith
- 3.1.S1Diagnose hierarchy issues (teammate missing instructions that live at user level)
- 3.1.S2Use @import to include relevant standards per package
- 3.1.S3Split large CLAUDE.md into .claude/rules/ topic files
- 3.1.S4Use /memory to see which memory files are loaded
Lock it in
Answer scenario questions on this topic. Every option comes with an explanation.
Practise 3.1 · 21 questions