CLAUDE.md hierarchy: managed, user, project, local

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. Every session you re-explain the same three things about your service: the build command, the test command, and where the request handlers live. A teammate joining next month would need the same context, and everyone who clones the project should get it without asking you. What's the most effective way to give Claude that context in every session?

   Right. In the game that’s Renown for your Claude Code Configuration and Workflows building.

   Not that one: C is right. In the game your Claude Code Configuration and Workflows building would lose a little Renown, and this question would come back later.

   Your answerA.Correct Claude until auto memory records the facts, which Claude writes for itself and keeps on one machine.Auto memory is written by Claude, not by you, and is machine-local. It is meant for your corrections and preferences, and Claude skips anything your CLAUDE.md files already say.Your answerB.Write the facts into ~/.claude/CLAUDE.md, which Claude reads at the start of every session on your own machine.~/.claude/CLAUDE.md holds personal preferences for all your projects on your machine. It is shared with just you, so a teammate who clones the project sees none of it.The answerC.Write the facts into a project CLAUDE.md committed with the repository, which Claude reads at the start of every session.CLAUDE.md files are markdown files that give Claude persistent instructions for a project. "You write these files in plain text; Claude reads them at the start of every session." A project CLAUDE.md at ./CLAUDE.md or ./.claude/CLAUDE.md carries build and test commands, layout and conventions, and reaches the whole team through source control.Your answerD.Write the facts into a skill committed with the repository, which Claude loads when it judges it relevant.A skill is not startup context. Skills load when you invoke them or when Claude decides one is relevant to the prompt, so the build and test commands would not be present at the start of a session.

   Written from code.claude.com/docs/en/memory.md

2. You run Claude Code from services/billing/ in a monorepo whose root CLAUDE.md sets a repository-wide four-space indentation rule. The billing team needs its own two-space rule to win in sessions started there, and each developer needs a personal override that wins over both and never reaches a commit. Where should you create the two overriding files?

   Right. In the game that’s Renown for your Claude Code Configuration and Workflows building.

   Not that one: B is right. In the game your Claude Code Configuration and Workflows building would lose a little Renown, and this question would come back later.

   Your answerA.The team rule in services/billing/CLAUDE.md, and the personal rule in ~/.claude/CLAUDE.md.User-scope instructions are the broadest, not the most specific. The scope table lists CLAUDE.md locations in load order from broadest to most specific, and ~/.claude/CLAUDE.md sits above every project file, so a project instruction appears in context after it. It also applies in every project on the machine.The answerB.The team rule in services/billing/CLAUDE.md, and the personal rule in services/billing/CLAUDE.local.md.Claude Code loads CLAUDE.md and CLAUDE.local.md from the working directory and every directory above it, and concatenates all of them into context rather than letting one replace another.Your answerC.The team rule in services/billing/CLAUDE.local.md, and the personal rule in ~/.claude/CLAUDE.md.CLAUDE.local.md is the private half of the pair. It is the file the documentation points at for personal project preferences and tells you to gitignore, so anything a team must share belongs in CLAUDE.md instead.Your answerD.The team rule in the root .claude/rules/billing.md, and the personal rule in services/billing/CLAUDE.md.Treats a root rules file as if it were scoped to the directory it describes. A rule with no paths frontmatter loads at launch with the same priority as .claude/CLAUDE.md, so it competes with the root file rather than overriding it, and the personal half would be committed.

   Show the full explanation and doc quotes

   Across the tree the content is ordered from the filesystem root down to the working directory, so services/billing/CLAUDE.md appears after the root file and is read last. Within a single directory CLAUDE.local.md is appended after CLAUDE.md, which puts a developer's personal notes last of all. CLAUDE.local.md is the file the documentation designates for private per-project preferences and tells you to add to .gitignore, so it is the half that never reaches a commit.

   Written from code.claude.com/docs/en/memory.md

3. You run long sessions from your monorepo's root. The root CLAUDE.md's conventions hold all the way through, but after each /compact the naming rules from packages/api/CLAUDE.md stop being applied, then start being applied again some turns later without you doing anything. What is the most likely root cause?

   Right. In the game that’s Renown for your Claude Code Configuration and Workflows building.

   Not that one: B is right. In the game your Claude Code Configuration and Workflows building would lose a little Renown, and this question would come back later.

   Your answerA.After compaction Claude re-reads the root CLAUDE.md from disk, and a nested file returns only when the conversation next names its directory.Nested instructions are tied to file reads, not to topics. Discussing the package without opening anything in it does not bring its CLAUDE.md back; reading a file there does.The answerB.After compaction Claude re-reads the root CLAUDE.md from disk, and a nested file returns only when Claude next reads a file under its directory."Project-root CLAUDE.md survives compaction: after /compact, Claude re-reads it from disk and re-injects it into the session. Nested CLAUDE.md files in subdirectories and rules with paths: frontmatter reload as Claude reads files they apply to." The gap you see is the interval between compaction and Claude next touching a file under packages/api/.Your answerC.Compaction discards every memory file, and only the ones Claude happens to open again during the session come back into context.The root file is re-read from disk and re-injected after compaction, which is why its conventions never lapse in your sessions. Only the on-demand files have a gap.Your answerD.Compaction keeps instructions given in conversation and drops instructions read from disk, so only re-typed rules survive it.It is the reverse. Instructions given only in conversation are the ones that disappear after compaction, which is why the guidance is to move them into CLAUDE.md so they persist.

   Written from code.claude.com/docs/en/memory.md