Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization

Claude Code builds its instruction set ("memory") by combining several CLAUDE.md files. The skill being measured is knowing which file a given instruction belongs in, and diagnosing the symptoms when it sits in the wrong one.

The three levels the exam grades

Level	Path	Applies to	Reaches teammates?
User	~/.claude/CLAUDE.md	every project that one user opens	No — never version-controlled
Project	.claude/CLAUDE.md or root CLAUDE.md	everyone who clones the repo	Yes
Directory	a CLAUDE.md inside a subdirectory	one package or service in the tree	Yes

The guide describes scoping and sharing here and nothing more. It states no precedence or override order, so on the exam an answer that ranks one level over another is inventing a rule — pick the option that reasons from who receives the file, never from which file wins.

That holds because in Claude Code nothing wins: every discovered file is concatenated into context rather than overriding another.³³ The order runs from the filesystem root down to your working directory, so the file closest to where you launched is read last. There is also a fourth location the guide does not cover — a managed policy CLAUDE.md that an organization deploys machine-wide and that individual settings cannot exclude. That is where a compliance standard belongs; a project file is the wrong instrument for a rule nobody may opt out of.

The diagnostic pattern

The "works on my machine" configuration bug: a senior engineer's conventions are honored in their sessions, but a new team member does not receive them. The cause is almost always instructions parked in user-level ~/.claude/CLAUDE.md instead of project-level configuration. The fix is to move them into the committed project file.

/memory is the instrument. It lists the memory files actually loaded in the current session, so you can see what Claude is really reading before theorizing about behavior that differs between sessions or teammates.³⁴

Keeping it modular

Two mechanisms stop CLAUDE.md from growing into an unreadable monolith.

Mechanism	What it does	Reach for it when
@import	references an external file from inside CLAUDE.md	each package should pull in only the standards its maintainers know apply
.claude/rules/	holds topic-specific rule files: testing.md, api-conventions.md, deployment.md	one file has grown too large to review or own

The split into .claude/rules/ also makes each topic separately reviewable, and it is the prerequisite for the path scoping in 3.3.³⁵

The trade-off to remember: project and directory files are shared and code-reviewed; user-level files are private and invisible to review. Anything the team must obey has to be committed.

# In each engineer's session, list the loaded memory files
/memory

# Move the team-relevant rules out of personal memory and commit them
git add CLAUDE.md .claude/rules/
git commit -m "chore: move error-handling and migration rules to project memory"

# API package

This package owns the public GraphQL schema.

## Standards that apply here

@docs/standards/graphql-conventions.md
@docs/standards/testing.md
@docs/standards/error-handling.md

## Local notes

- Resolvers live in `src/resolvers/`; never call the database directly from a resolver.
- Schema changes require a matching entry in `CHANGELOG.md`.

repo/
  CLAUDE.md                  # short: what the project is, how to build it
  .claude/
    rules/
      testing.md             # test layout, fixtures, coverage expectations
      api-conventions.md     # versioning, error envelope, pagination
      deployment.md          # release process, migration safety
  packages/
    api/CLAUDE.md            # directory-level, @imports the API standards
    web/CLAUDE.md