Lesson 5 · Domain 3 — Claude Code Configuration & Workflows (20% of exam)

CLAUDE.md Hierarchy & Path-Scoped Rules

New domain. Domain 3 is about configuring Claude Code itself for real team workflows — and the first thing to get straight is where instructions live, because "Claude isn't following our conventions" is almost always a hierarchy problem, not a prompting problem.

Three levels, one clear rule about sharing

This single fact resolves a whole category of "why isn't this working" questions: if a new teammate clones the repo and Claude doesn't follow team conventions for them, the conventions almost certainly live in someone's personal ~/.claude/CLAUDE.md instead of the project-level file. Run /memory to see exactly which memory files are actually loaded for a session — it's the fastest way to diagnose this.

@import for modular configuration

<!-- .claude/CLAUDE.md -->
# Project conventions
@import ./docs/api-conventions.md
@import ./docs/testing-standards.md

@import keeps a single monolithic CLAUDE.md from becoming unmanageable — reference external files instead of inlining everything, and let each package maintainer own their own imported slice.

.claude/rules/: scoping by file pattern, not by folder

Directory-level CLAUDE.md scopes by where a file lives. That breaks down the moment a convention needs to apply to files scattered across the tree regardless of location — the textbook case being test files sitting right next to the code they test (Button.test.tsx beside Button.tsx), everywhere in the codebase.

---
paths:
  - "**/*.test.tsx"
  - "**/*.test.ts"
---
Tests use Vitest + Testing Library. Mock network calls with msw, never fetch directly.

A rule file in .claude/rules/ with a paths glob in its YAML frontmatter loads only when Claude is editing a matching file — regardless of which directory that file happens to be in. That's strictly better than either a bloated root CLAUDE.md (loaded always, for every file) or dozens of per-directory CLAUDE.md files (which can't express "any file matching this pattern, anywhere").

Match the tool to the shape of the convention
If a convention is scoped by location (everything under terraform/), directory-level CLAUDE.md or a rule with a directory glob both work. If it's scoped by file type or pattern that cuts across the whole tree, only a glob-based rule in .claude/rules/ actually holds up. Relying on Claude to infer which section of one giant CLAUDE.md applies is not a reliable substitute for either.

Why this matters beyond the exam

Primary source: Anthropic's Extend Claude Code documentation covers CLAUDE.md, imports, and memory files directly — this lesson compresses Task Statements 3.1 and 3.3 from the official exam guide.

Check your understanding

Q1. Test files sit throughout the codebase next to the code they test, and you want the same conventions applied automatically no matter where a test file lives. What's the most maintainable fix?
Q2. A new teammate clones the repo, but Claude doesn't seem to follow the team's conventions for them. What's the most likely cause?
Q3. What does @import let you do inside CLAUDE.md?

Want to see how .claude/rules/ frontmatter compares to skill frontmatter, which is coming up next? Just ask.

← Lesson 4: Task Decomposition Study Plan Lesson 6: Commands vs. Skills →