Domain 3 — Claude Code Configuration & Workflows

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 guide describes scoping and sharing here and nothing more. It states no precedence or override order between the levels, so an answer that ranks one level over another is inventing a rule.

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.

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.

Slash commands and Agent Skills package a repeatable workflow so a developer can invoke it on demand instead of retyping a prompt. The exam tests where you put them, which decides who gets them, and how you configure them, which decides how they behave.

Scoping: who receives it

The different name is the point of the last row: it keeps the team's version working untouched while you run your own.

Skill frontmatter

A skill lives in a SKILL.md file whose YAML frontmatter configures how it runs. Three options are tested.

Do not confuse this "fork" with Domain 1's fork_session (1.7). context: fork isolates a skill's output so it never enters the main conversation; fork_session creates branches that inherit a shared analysis baseline.

Skills vs CLAUDE.md

This is the recurring judgment call, and it turns on load timing.

So a rarely used, verbose procedure sitting in CLAUDE.md is in the wrong place. Move it to a skill and it leaves every session's context while staying one command away.

Path-specific rules solve a targeting problem. Directory-level CLAUDE.md files scope conventions by location; path-specific rules scope them by file pattern. Many real conventions are file-type conventions, and those files are scattered across the tree.

A rule file in .claude/rules/ can carry YAML frontmatter with a paths field containing glob patterns. The rule is then activated conditionally: it loads only when the files being edited match one of those globs. A Terraform rule with paths: ["terraform/**/*"] is invisible while you work on the React frontend, and appears the moment you touch infrastructure code.

Why conditional loading matters

Two effects, and the exam cares about both:

• Less irrelevant context. Claude is not reading Terraform naming conventions while fixing a CSS bug, so the instructions it does see are all relevant to the task.
• Lower token usage. Always-loaded memory is paid for in every session. Path-scoped rules are paid for only in the sessions that need them, which is what lets a large team keep a genuinely detailed rule set without bloating every conversation.

Globs vs directory-level CLAUDE.md

This is the discrimination the exam tests. Use a directory-level CLAUDE.md when the convention really is about a place: everything under services/billing/ must go through the ledger client. Use a path-scoped rule when the convention is about a kind of file that spans multiple directories:

• **/*.test.tsx — test conventions, when tests sit next to the code they test all over the repo.
• **/migrations/*.sql — migration safety rules, one folder per service.
• terraform/**/* — infrastructure conventions.

With directory-level files you would have to duplicate the same test conventions into a CLAUDE.md in every directory that happens to contain tests, and then keep those copies in sync forever. A single glob-scoped rule file expresses the intent once, applies it by file type regardless of directory location, and stays out of context when it does not apply.

Path-scoped rule or skill?

Migrations show up on both sides of this line, so fix the discriminator now. A procedure you invoke — the steps for generating a migration — belongs in a skill (3.2). A convention that should apply whenever you edit matching files — migrations must be reversible — belongs in a path-scoped rule. Same subject, different trigger: one is called on demand, the other activates from the files being edited.

The mental model: paths turns a rule from "always on" into "on when relevant", and the glob is how you express relevance.

Plan mode and direct execution are two ways to spend Claude Code's effort, and choosing wrongly is expensive in both directions. The exam gives you a task description and asks which one fits, so read it for signals.

Signal to choice

Why discovery gets its own row

Discovery is the phase that quietly exhausts a context window. Tracing how authentication flows through an unfamiliar service can mean reading dozens of files, and every one of them lands in the main conversation. Delegating that reading is what leaves room for the planning and the implementation that come after it.

Why the combination is not a compromise

Plan mode and direct execution are not exclusive, and the guide says so explicitly. Plan the library migration — inventory the call sites, decide the sequencing, choose the compatibility shim — then execute the agreed approach directly, step by step, without re-planning each file.

The exam's framing: complexity and irreversibility push toward planning; clarity and small blast radius push toward direct execution.

Iterative refinement is the craft of turning a mediocre first result into a correct one with the fewest, best-targeted follow-up messages. The exam tests four specific techniques and, crucially, when each one applies.

Concrete input/output examples

When prose descriptions are interpreted inconsistently, concrete input/output examples are the most effective way to communicate the expected transformation. "Normalize the address field" can mean five things; two or three worked pairs — this input becomes exactly this output — pin the semantics down in a way no adjective can. The guide's guidance is 2–3 examples: enough to show the pattern and its edge, not so many that you are writing the test suite by hand. Keep that figure attached to its scope — 2–3 is the count for input/output pairs used in iterative refinement, and it is a different statement from Domain 4 §4.2's 2–4 targeted few-shot examples for ambiguous-case prompting. A stem asking "how many examples?" is answered by which of the two techniques it describes. This is also the fix for a specific edge-case failure: supply a concrete input containing the problem value (a null, an empty string, a date at a boundary) alongside the exact expected output.

Test-driven iteration

Write the test suite first, covering expected behavior, edge cases and performance requirements, then let Claude implement against it and iterate by sharing the failures. Each failure is unambiguous, machine-generated feedback: no interpretation gap, no argument about whether the behavior is correct. Progressive improvement is then just a loop — run tests, paste failures, repeat — and the loop has an objective stopping condition.

The interview pattern

In an unfamiliar domain, you do not know what you failed to specify. The interview pattern inverts the flow: ask Claude to ask you questions before implementing. Prompting for questions about a caching layer surfaces invalidation strategy, stampede behavior, and what happens when the cache is unavailable — considerations the developer may not have anticipated. It converts unknown unknowns into an answerable list, before code exists that assumes the wrong answers.

Batch or sequential?

The judgment call the exam likes most. Give all issues in a single detailed message when the problems interact — if fixing the retry logic changes how the timeout should behave, fixing them one at a time makes each fix invalidate the last. Fix sequentially when the problems are independent, because smaller focused messages produce more reliable, easier-to-verify changes and you can stop early if one fix reveals something new.

The unifying principle: reduce ambiguity per round trip. Examples, tests, and questions are all ways of making the next iteration's feedback specific.

Running Claude Code in a pipeline changes three things: there is no human to answer prompts, the output must be parsed by a machine, and the session has no accumulated project knowledge unless you give it some.

Surface by surface

What matters for the exam is that the two output flags exist and are used together. The way a schema is handed to --json-schema in the snippets below — a path to a schema file — is written as an illustration, not as a quoted argument specification.

This is the CLI/CI layer. At the API layer the equivalent mechanism is tool use with a JSON input_schema (Domain 4, task statement 4.3), which is described there as the most reliable way to guarantee schema-compliant output. Same goal — a shape the caller can rely on — enforced at two different layers, so read the stem for which one it is asking about.

Session context isolation

A subtle but heavily tested point: the same session that generated code is less effective at reviewing its own changes than an independent review instance. The generating session carries the assumptions and justifications that produced the code, so it is primed to consider them correct. A fresh instance judges the diff on its merits, which is why the review step is its own job in the pipeline.

Noise is a context problem, not a model problem

Two of those rows are the same move made twice: hand the run the context that lets it stay quiet. Undocumented fixtures produce hand-rolled objects and trivial assertions. Missing prior findings produce a thread of repeats. Either way the team learns to ignore the bot, and that is the real cost.