CLAUDE.md is a markdown file that Claude Code loads at the start of every session. We use it to set coding standards, architecture decisions, preferred libraries, and conventions. These five questions cover what you should know about managing it in your projects.
I publish Agentic Coding Weekly every Monday. If you want new quizzes like these in your inbox, subscribe below.
Questions
Q1: Your team wants to share project-level Claude Code instructions via version control, but you also have personal sandbox URLs and test credentials you use locally. Where should you put your private, project-specific preferences?
A) ~/.claude/CLAUDE.md
B) ./CLAUDE.md with a comment marking them as personal
C) ./CLAUDE.local.md
D) ./.claude/rules/personal.md
Q2: Your project's instructions are getting big. What's the most maintainable way to structure them without creating a single massive CLAUDE.md?
A) Split topic-specific guidance into ./.claude/rules/*.md
B) Keep everything in ./CLAUDE.md and rely on headings
C) Put everything into README and tell Claude to read it
D) In ~/.claude/rules/ so they apply everywhere
Q3: You want certain rules to apply only when Claude is working on TypeScript files under src/ and lib/. How do you scope a rule file to specific paths?
A) Name the rule file after the directory, e.g., src.md
B) Place the rule file inside the target directory
C) Add a paths field in YAML frontmatter at the top of the rule file
D) Use an @include directive in the project CLAUDE.md
Q4: Your CLAUDE.md contains the line @docs/git-instructions.md to pull in shared git workflow instructions. How is this path resolved?
A) Relative to the git repository root
B) Relative to the file containing the import
C) As an absolute path from the system root
D) Relative to the current working directory where Claude Code was launched
Q5: You want Claude to load CLAUDE.md files from an extra directory provided via --add-dir. What do you need to do?
A) Nothing, --add-dir automatically loads all memory files from that directory
B) Copy those CLAUDE.md files into your main repo
C) Only organization-managed policy can enable cross-directory memory loading
D) Set the CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 environment variable
Answers and Explanations
Q1: Correct Answer is C.
Explanation: Claude Code has a memory hierarchy with different files serving different scopes. Team instructions go in ./CLAUDE.md (or ./.claude/CLAUDE.md) and get checked into version control. Personal, project-specific preferences go in ./CLAUDE.local.md, which is automatically added to .gitignore so it never gets committed. Option A (~/.claude/CLAUDE.md) is user-level memory, which applies globally across all projects, so it's the wrong place for project-specific things like sandbox URLs. Option D (./.claude/rules/personal.md) would get committed with the repo since everything in .claude/rules/ is meant to be shared.
Q2: Correct Answer is A.
Explanation: The .claude/rules/ directory is purpose-built for this. You create focused files like testing.md, api-design.md, security.md, and optionally organize them into subdirectories like frontend/ and backend/. All .md files in this directory are automatically discovered and loaded as project memory, including files in nested subdirectories. This keeps rules reviewable in PRs and easy to find. A single large CLAUDE.md becomes hard to maintain as team grows, and putting instructions in README mixes concerns that should stay separate.
Q3: Correct Answer is C.
Explanation: Any rule file in .claude/rules/ can include YAML frontmatter with a paths field that accepts glob patterns. For example, adding paths: ["src/**/*.{ts,tsx}", "lib/**/*.ts"] at the top of a rule file means those instructions only activate when Claude is working with matching files. Rules without a paths field load unconditionally and apply to all files. This is particularly useful in polyglot repos or monorepos where Python API conventions shouldn't be taking up context when Claude is editing React components. Brace expansion works too, so *.{ts,tsx} matches both extensions. The file naming convention (option A) has no effect on scoping, and placing files inside source directories (option B) is not how project rules work.
Q4: Correct Answer is B.
Explanation: The @path/to/file import syntax resolves relative to the file that contains the import, not the working directory or repo root. So if ./CLAUDE.md at the project root contains @docs/git-instructions.md, it resolves to ./docs/git-instructions.md from that file's location. This becomes important when CLAUDE.md files are present at multiple levels of project, because each file resolves its own imports independently. Imports also support absolute paths and ~ for home directory references, which is useful for sharing personal instructions across git worktrees. One other thing worth knowing: imports can be recursive up to 5 levels deep, and the first time Claude encounters imports in a project, it shows an approval dialog. If you decline, imports stay disabled for that project and the dialog won't reappear, so don't decline by accident.
Q5: Correct Answer is D.
Explanation: The --add-dir flag gives Claude file access to another directory, but it intentionally does not load memory files from it by default. This is a deliberate safety measure so that adding a directory for file access doesn't unexpectedly alter Claude's behavior with instructions you might not have reviewed. To opt in to loading memory files (including CLAUDE.md, .claude/CLAUDE.md, and .claude/rules/*.md) from those additional directories, you set CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1.
