A single giant CLAUDE.md is the common failure: it burns context on every turn and mixes rules that apply everywhere with rules that apply to one package. Build a layered memory hierarchy in a realistic monorepo and verify the load behaviour.
What to build
- Create a repo with at least three packages that have genuinely different conventions.
- Write a root CLAUDE.md containing only what is true everywhere.
- Add a package-level CLAUDE.md to each package with its local rules.
- Confirm which files load automatically and which load on demand when Claude reads into a subdirectory.
- Use an @path import to pull in a shared standards file without duplicating it.
- Measure the context cost of the root file and trim it.
Done when
- No rule appears in two files.
- The root file contains nothing package-specific.
- You can describe the load order and which files are read up front.
- The imported standards file is maintained in exactly one place.
If you want to go further
- Add a personal ~/.claude/CLAUDE.md preference and confirm it applies across projects without entering the repo.
The trap this exercise teaches
Believing user-scope memory lives in ~/.claude.json. It does not — that file holds session and MCP server state. User memory is ~/.claude/CLAUDE.md.
Before you start
The theory behind this build is covered in The CLAUDE.md hierarchy and load order. If any step below is unfamiliar, read that first — the exercise assumes it. Primary source: Claude Code Docs — Memory.
Check yourself against the exam
This exercise sits in Domain 2, which is 20% of the CCAR‑F exam. Once you have built it, run a domain drill in the study app and see whether the questions read differently.