CLAUDE.md Hierarchy, @import and Path-Scoped Rules Explained

The exam guide names three levels:

Claude Code combines all applicable files rather than letting one override another, with more specific files read later. The current docs also list a managed policy file for organizations and a gitignored CLAUDE.local.md for personal per-project notes, but the exam centres on the three levels above.

The classic diagnosis: rules that don't reach a new teammate

Expect this scenario: a senior developer has tuned Claude's behaviour for months. A new teammate clones the repo, and Claude ignores the testing and naming conventions everyone else relies on.

The conventions were in the senior developer's ~/.claude/CLAUDE.md. User-level instructions apply only to that user and are never shared through version control. The fix is to move team conventions into the project-level CLAUDE.md (or .claude/rules/) and commit them, keeping only personal preferences at user level.

To check what is loaded, the guide points to the /memory command, which lists the memory files Claude Code uses across user and project scopes and opens them for editing. In current Claude Code versions, /context also shows which CLAUDE.md and rules files loaded at launch.

A single CLAUDE.md that covers every package in a monorepo gets long, and long instructions are followed less consistently. The @import syntax pulls other files in by path:

# packages/billing/CLAUDE.md
@../../docs/standards/api-conventions.md
@../../docs/standards/money-handling.md

Billing-specific notes go here.

Relative paths resolve from the file that contains the import. Imports can nest (the docs allow up to four hops). The exam skill here is selective inclusion: each package's CLAUDE.md imports only the standards files its maintainers know are relevant, so the billing package gets money-handling rules and the docs site doesn't.

One thing to keep in mind: imports organize instructions but don't save tokens. Imported files load along with the CLAUDE.md that references them.

The .claude/rules/ directory replaces a monolithic CLAUDE.md with focused topic files:

repo/
├── CLAUDE.md                 # short: project overview, build commands
├── .claude/
│   └── rules/
│       ├── api-conventions.md
│       ├── deployment.md
│       └── testing.md        # paths: ["**/*.test.tsx"]
└── src/
    ├── checkout/Cart.test.tsx
    └── profile/Avatar.test.tsx

A rule file without frontmatter loads every session, like CLAUDE.md. Add a paths field with glob patterns and the rule loads only when Claude works with a matching file:

---
paths:
  - "**/*.test.tsx"
---

# Component test conventions

- Use React Testing Library queries by role, not by test ID.
- One behaviour per test; name tests "does X when Y".
- Mock network calls with the shared handlers in test/msw.

Irrelevant conventions stay out of context, and the rule follows the file type instead of the folder.

Why path-scoped rules beat a subdirectory CLAUDE.md here

A subdirectory CLAUDE.md is tied to one directory. Test files in this repo sit next to their components in checkout/, profile/ and dozens of other folders. To cover them with directory-level files you would copy the same test conventions into every folder and keep them in sync. One testing.md with paths: ["**/*.test.tsx"] applies to every test file wherever it lives. The same goes for terraform/**/* or **/*.sql conventions.

Use a subdirectory CLAUDE.md when the rules really belong to one directory, such as a legacy module with its own build quirks.

A related exam distinction from task statement 3.2: CLAUDE.md holds universal standards that should apply in every session, so it is always loaded. Skills (.claude/skills/<name>/SKILL.md) hold task-specific workflows, such as a release checklist or a migration procedure, and load only when invoked. If an instruction matters only for one kind of task, it is a skill. If it matters only for one kind of file, it is a path-scoped rule. If it matters everywhere, it goes in CLAUDE.md.

For how skills, commands and subagents compare, see skills vs commands vs subagents.

A team keeps React component tests next to each component across about 40 feature folders. They want Claude Code to follow specific testing conventions whenever it edits a test file, without loading those conventions when it edits other code. What should they do?

A. Add a CLAUDE.md with the testing conventions to each of the 40 feature folders. B. Put the conventions in each developer's ~/.claude/CLAUDE.md. C. Create .claude/rules/testing.md with paths: ["**/*.test.tsx"] frontmatter and commit it. D. Add the conventions to the root CLAUDE.md under a "Testing" heading.

Answer: C. A glob-scoped rule matches test files by type across all folders, loads only when a matching file is in play, and is shared through version control.

• A works but duplicates the same content 40 times and drifts as folders are added.
• B is user-level, so it isn't shared, and new teammates won't get it.
• D is shared, but the conventions load in every session, including ones that never touch a test.

• User-level ~/.claude/CLAUDE.md is personal and unshared. Team rules go in the project CLAUDE.md or .claude/rules/, committed to the repo.
• "New teammate doesn't get the rules" usually means the rules are at user level.
• @import keeps CLAUDE.md modular and lets each package include only the standards it needs.
• .claude/rules/ files with paths globs load only for matching files and beat directory CLAUDE.md files for conventions spread across the codebase.
• Use /memory to check which memory files are loaded when behaviour differs between sessions.