Domain 3 is worth 20% — roughly 12 questions out of 60 — and it's by far the most factual of the five: most questions have an exact answer you can verify in the Claude Code documentation. Where a file goes, which flag enables what, which scope is shared via version control. That's also why it yields the most points per hour of revision: you're not asked to judge, you're asked to know. Candidates who lose points here almost always confuse two scopes (user vs project) or two neighboring mechanisms (command vs skill, directory CLAUDE.md vs glob rule).
This lesson follows the 6 task statements of the official exam guide v1.0 (July 2026). The exam scenarios that lean on this domain are Code Generation with Claude Code (scenario 2), Developer Productivity (scenario 4) and Claude Code for Continuous Integration (scenario 5).
The domain map
The six task statements fall into two groups: configure (3.1 CLAUDE.md, 3.2 commands and skills, 3.3 path-scoped rules) and work (3.4 plan mode, 3.5 refinement, 3.6 CI/CD). The first group is pure fact; the second requires a judgment of proportion.
3.1 — CLAUDE.md: hierarchy, scope, modularity
CLAUDE.md is the instructions file Claude Code loads automatically. The whole task statement revolves around one question: who sees what, and from where.
What you need to know
Three levels. User: ~/.claude/CLAUDE.md, applies to all of that user's projects, not shared via version control. Project: CLAUDE.md at the root or .claude/CLAUDE.md, version-controlled, applies to the whole team. Directory: a CLAUDE.md in a subfolder, only concerning what's beneath it.
The classic diagnostic. "A new team member isn't getting the instructions the others have." Expected cause: the instructions are at user level (on each veteran's machine) and not at project level. The fix is moving them into the project CLAUDE.md. Same logic as .mcp.json vs ~/.claude.json in Domain 2.
@import. Syntax for referencing an external file from a CLAUDE.md, to keep it short. Expected use: in a monorepo, each package's CLAUDE.md selectively imports the standards files that concern it, chosen by the maintainers who know the domain.
.claude/rules/. Directory of topic-specific rule files (testing.md, api-conventions.md, deployment.md) as an alternative to a monolithic CLAUDE.md. With a paths: frontmatter they become conditional (§3.3).
/memory. Command that shows which memory files are actually loaded. It's the first reflex when behavior is inconsistent across sessions: check what's really loaded before rewriting anything.
<!-- packages/api/CLAUDE.md — directory level, imports only the relevant standards -->
# API package
@../../docs/standards/api-conventions.md
@../../docs/standards/error-handling.md
Handlers in async/await, errors via `AppError`, never `console.log` in production.~/.claude/CLAUDE.md" or "send them to the team by message": both bypass version control; the expected answer is project level. Another trap: proposing one CLAUDE.md per subfolder for conventions that concern scattered files (tests next to their code everywhere in the tree) — that's question 6 of the guide, and the answer is .claude/rules/ with a glob (§3.3).@import or .claude/rules/. Inconsistent behavior → /memory first.3.2 — Commands and skills: where, and with which frontmatter
Two on-demand invocation mechanisms, each with a project scope and a personal scope. The exam tests the scope and the three frontmatter options of skills.
What you need to know
Commands. .claude/commands/<name>.md in the repo: shared, available to any developer who clones or pulls (question 4 of the guide). ~/.claude/commands/<name>.md: personal. Neither CLAUDE.md nor a hypothetical .claude/config.json with a commands array — the latter doesn't exist and serves as a distractor.
Skills. .claude/skills/<name>/SKILL.md, with YAML frontmatter. Three options to know:
context: fork— the skill runs in a subagent with isolated context; its output doesn't pollute the main conversation. Use cases: a verbose codebase analysis, an exploratory brainstorm of alternatives.allowed-tools— restricts the tools accessible during skill execution (e.g. limiting to file writes to prevent a destructive action via Bash).argument-hint— text shown to prompt the developer for the expected parameters when invoking the skill without arguments.
Personal variant. To customize a team skill without affecting others, you create a variant in ~/.claude/skills/ under a different name. Modifying the shared skill affects everyone.
Skill vs CLAUDE.md. A skill is invoked on demand for a specific workflow. CLAUDE.md is always loaded: universal standards, permanent conventions. If the question says "every session, without anyone asking", it's CLAUDE.md; if it says "when a developer runs task X", it's a skill.
<!-- .claude/skills/analyze-codebase/SKILL.md -->
---
name: analyze-codebase
description: Maps a module, lists entry points, dependencies and risk areas.
context: fork
allowed-tools: [Read, Grep, Glob]
argument-hint: "<module path> [--depth N]"
---
Analyze the given module. Return ONLY a structured summary:
entry points, external dependencies, high-coupling areas, existing tests.<!-- .claude/commands/review.md — team command, version-controlled -->
Review the pending changes against the team checklist:
security (injections, secrets), error handling, tests covering branches, readability.
Format: file · line · severity · issue · proposed fix.~/.claude/commands/ (personal). Putting a command definition in CLAUDE.md (that's for instructions, not commands). Modifying the shared skill for a personal need (team impact) instead of creating a differently named variant. And confusing context: fork (context isolation) with allowed-tools (tool restriction): the first protects the conversation, the second protects the system.3.3 — Path-scoped rules: conditional loading
This is question 6 of the official guide, and one of the most discriminating items of the domain. A codebase with different conventions per area (React components, API handlers, data models), and test files spread everywhere next to the code they test. How do you automatically apply the right convention?
What you need to know
The mechanism. A file in .claude/rules/ with a YAML frontmatter containing paths: and a list of globs. The rule only loads when Claude edits a matching file.
Two benefits. Functional: the convention applies by file type, regardless of location (**/*.test.tsx catches all tests). Economic: irrelevant context isn't loaded, which reduces tokens.
When to pick the glob over the directory. As soon as the concerned files are spread across several folders. A directory CLAUDE.md remains valid for a scope really bounded by a folder.
Why not the other options of question 6. Consolidating everything in the root CLAUDE.md "letting Claude infer which section applies": relies on inference, not explicit matching. Skills per code type: require invocation, contradict "automatically".
<!-- .claude/rules/testing.md -->
---
paths: ["**/*.test.tsx", "**/*.test.ts", "**/__tests__/**"]
---
Tests with Vitest. One `describe` per public function. Nominal case, edge cases, errors.
No database mocks: use the fixtures in `test/fixtures/`.
Naming: `it("returns X when Y")`.CLAUDE.md per subfolder" — it works for an area, it doesn't work for a spread file type. Spot the words spread throughout, alongside, regardless of location: they point at the glob. And mind the syntax: it's paths: in YAML frontmatter, not a comment in the body..claude/rules/*.md with paths: [glob]. Grouped in a folder → directory CLAUDE.md. Universal → project CLAUDE.md.3.4 — Plan mode or direct execution
Question 5 of the guide: restructure a monolith into microservices, dozens of files, service boundary decisions. Answer: plan mode first. The difficulty isn't that question, it's recognizing the cases where plan mode is unnecessary.
What you need to know
Plan mode. For tasks with large changes, several valid approaches, architectural decisions, multi-file modifications. It lets you explore the codebase and design before committing, which avoids costly rework. Guide examples: microservice restructuring, library migration touching 45+ files, choosing between two integration approaches with different infrastructure requirements.
Direct execution. For a simple, well-scoped change: a fix in one file with a clear stack trace, adding a date validation conditional.
The Explore subagent. During verbose discovery phases (reading dozens of files), it isolates the output and only returns a summary to the main context, which prevents window exhaustion on multi-phase tasks.
The combination. Plan mode for investigation and design, then direct execution to implement the planned approach.
3.5 — Iterative refinement: making Claude Code converge
A more "method" than "configuration" section. Four techniques, and above all the rule for deciding between a grouped message and sequential iterations.
Four refinement techniques and their trigger
| Symptom | Expected technique | |
|---|---|---|
| I/O examples | The prose description is interpreted inconsistently | 2-3 concrete input → expected output examples |
| Tests first | The code "works" but misses edge cases or performance | Write the test suite (nominal, edges, perf), then iterate by sharing failures |
| Interview pattern | Unfamiliar domain, unanticipated considerations (cache invalidation, failure modes) | Have Claude ask its questions BEFORE implementing |
| Targeted test case | A specific edge case fails (null in a migration) | Provide the exact input and expected output for that case |
| Grouped vs sequential | Several problems to fix | One detailed message if they INTERACT; sequential if independent |
What you need to know
Input/output examples. The most effective way to communicate an expected transformation when prose is interpreted inconsistently. Two or three concrete examples beat a paragraph of description.
Test-driven iteration. First write the test suite covering expected behavior, edge cases and performance requirements; then iterate by sharing test failures, which guide the fix precisely.
The interview pattern. Before implementing in an unfamiliar domain, have Claude ask questions to surface the considerations the developer hadn't anticipated: cache invalidation strategy, failure modes, consistency constraints.
Grouped or sequential. If the problems interact (fixing one changes the solution to another), you describe them all in a single detailed message so the solution is coherent. If they're independent, you handle them one after another.
3.6 — Claude Code in CI/CD
Scenario 5 (automated PR review, test generation) relies on this section. It contains the most "free" item of the exam — the -p flag — and one of the subtlest — review by an independent instance.
What you need to know
-p / --print. Non-interactive mode: Claude Code processes the prompt, writes to stdout and exits. Without this flag, the job waits for input and hangs indefinitely (question 10 of the guide). The distractors are non-existent features (CLAUDE_HEADLESS=true, --batch) or Unix hacks (< /dev/null).
--output-format json and --json-schema. To produce structured, validated results the pipeline can use: post each finding as an inline PR comment, filter by severity, count.
CLAUDE.md as CI context. Test standards, fixture conventions, review criteria: that's where CI learns what matters to the team. Documenting test standards and available fixtures directly reduces low-value generated tests.
Avoiding duplicates. On a re-review after new commits, you include the previous findings in context with the instruction to report only new or still-unaddressed issues. For test generation, you provide the existing test files so as not to suggest scenarios already covered.
Session isolation. A session that generated code is less effective at reviewing its own changes than an independent instance: it retains its reasoning and tends not to question its decisions. For review, you launch a fresh instance without the generation context (a theme picked up in Domain 4, multi-instance review).
# CI step: non-interactive review, structured output, previous findings as context
claude -p "Review this PR against the criteria in CLAUDE.md. \
Previous findings (report only new or still-unaddressed): $(cat prev-findings.json)" \
--output-format json \
--json-schema review.schema.json \
> findings.json
# The pipeline parses findings.json and posts inline comments
jq -c '.findings[] | select(.severity != "info")' findings.json | while read f; do
post_pr_comment "$f"
done{
"type": "object",
"properties": {
"findings": {
"type": "array",
"items": {
"type": "object",
"properties": {
"file": {"type": "string"},
"line": {"type": "integer"},
"severity": {"type": "string", "enum": ["critical", "high", "medium", "low", "info"]},
"issue": {"type": "string"},
"suggested_fix": {"type": "string"},
"detected_pattern": {"type": "string"}
},
"required": ["file", "line", "severity", "issue"]
}
}
},
"required": ["findings"]
}-p / --print is a distractor (invented environment variable, invented flag, stdin redirection). On review: "ask the same session to re-read its code with a stronger self-critique instruction" or "enable extended thinking for self-review" don't replace an independent instance. On duplicates: "reduce review frequency" isn't the answer — injecting previous findings is.-p. Parseable → --output-format json + --json-schema. Too noisy → criteria and standards in CLAUDE.md. Duplicates → previous findings / existing tests in context. Review → independent instance.Cross-cutting traps of Domain 3
- Shared = version-controlled = project. Anything that must reach a teammate via
git clonelives under.claude/or at the repo root. Anything under~/is personal. - Explicit matching beats inference. A glob rule applies by construction; "Claude will infer the right section" only applies by luck.
- Stated complexity isn't discovered. If the prompt describes a large task, you plan from the outset.
- Invented features are distractors.
--batch,CLAUDE_HEADLESS, acommandsarray inconfig.json: they don't exist.
Night-before checklist
~/.claude/CLAUDE.md = user, never shared; root CLAUDE.md or .claude/CLAUDE.md = project, version-controlled; subfolder = directory, bound to location.
- New member without instructions → they're at user level, move them to project level.
- @import to reference standards files and keep CLAUDE.md modular.
- .claude/rules/*.md = topic rules; with paths: [globs] = conditional loading.
- /memory to see what's loaded — first diagnostic reflex.
- Commands: .claude/commands/ (project) vs ~/.claude/commands/ (personal); never in CLAUDE.md, never config.json.
- Skills: .claude/skills/<name>/SKILL.md; context: fork (isolation), allowed-tools (restriction), argument-hint (parameters).
- Personal variant of a team skill → ~/.claude/skills/ under a different name.
- Skill = on demand, CLAUDE.md = always loaded.
- Files spread by type → glob rule (**/*.test.tsx), not per-folder CLAUDE.md.
- Plan mode: large, multi-file, architecture, several approaches. Direct: scoped, single file, clear stack trace.
- Explore: isolates verbose discovery, returns a summary.
- Combine: plan to investigate, direct to implement.
- Inconsistent prose → 2-3 I/O examples. Edge cases → tests first. Unknown domain → interview.
- Interacting problems → one message; independent → sequential.
- CI: -p / --print or the job hangs; --output-format json + --json-schema.
- CLAUDE.md = review criteria, test standards, fixtures.
- Duplicates → previous findings / existing tests in context.
- Review → independent instance, not the session that generated.Five original scenario questions, corrected
Questions written by nAIvigate in the spirit of the exam, reproducing no real items.
Question 1 — Code generation scenario. Three senior developers get reviews that follow team conventions; the intern who arrived yesterday gets generic reviews. The conventions are in each senior's ~/.claude/CLAUDE.md. Fix?
A. Send the file to the intern so they copy it into their ~/.claude/. B. Move the conventions into the CLAUDE.md at the repo root, version-controlled. C. Create a /conventions skill everyone invokes at session start. D. Add the conventions to .mcp.json.
📚Answer Q1
B. Team instructions → project level, shared via version control. A doesn't scale and drifts. C imposes manual invocation for universal standards (that's CLAUDE.md's role). D confuses MCP configuration with instructions.
Question 2 — Productivity scenario. A codebase analysis skill produces 4,000 lines of output that saturate the main conversation, and it once deleted a file via Bash. Which frontmatter?
A. context: fork and allowed-tools: [Read, Grep, Glob]. B. argument-hint and allowed-tools: [Bash]. C. context: fork only. D. Move the skill to ~/.claude/skills/.
📚Answer Q2
A. Two problems, two options: context: fork isolates the verbose output in a subagent; allowed-tools without Bash prevents the destructive action. C only addresses half. B and D are off-topic.
Question 3 — Code generation scenario. Terraform conventions must apply to .tf files present in infra/, modules/ and envs/prod/. Most maintainable approach?
A. One CLAUDE.md in each of the three folders. B. A .claude/rules/terraform.md file with paths: ["**/*.tf"]. C. Everything in the root CLAUDE.md under a "Terraform" heading. D. A /terraform skill to invoke before each edit.
📚Answer Q3
B. Files spread by type → glob rule, loaded only when editing .tf. A duplicates and misses the next folder. C relies on inference. D contradicts automatic application.
Question 4 — CI scenario. The review job generates the same 12 comments on every push to the PR, including for points already fixed. Fix?
A. Only run the review when the PR is opened. B. Include the previous findings in the prompt with the instruction to report only new or still-unaddressed issues. C. Switch to --output-format text. D. Ask Claude to be "more concise".
📚Answer Q4
B. The expected pattern is injecting previous findings. A removes review of the fixes. C degrades parseability. D is probabilistic and doesn't address the cause.
Question 5 — CI scenario. The pipeline generates code with Claude Code then asks it, in the same session, to review that code "with a very critical eye". Reviews almost never flag anything. What do you do?
A. Enable extended thinking for the review phase. B. Strengthen the self-critique instruction. C. Run the review in an independent instance, without the generation context. D. Do three reviews in the same session and merge.
📚Answer Q5
C. A session that generated retains its reasoning and rarely questions its choices; session isolation is the answer. A and B stay in the same session. D triples the bias instead of removing it.
Validation quiz
Where to put a /review command available to the whole team when cloning the repo?
📚Domain 3 glossary (expand)
CLAUDE.md — Instructions file loaded automatically by Claude Code; exists at user, project and directory levels.
User level — ~/.claude/CLAUDE.md: applies to all the user's projects, never shared via version control.
Project level — CLAUDE.md at the root or .claude/CLAUDE.md: version-controlled, shared by the team.
Directory level — CLAUDE.md in a subfolder: applies only to files beneath it.
@import — Syntax for referencing an external file from CLAUDE.md to keep it modular.
.claude/rules/ — Directory of topic-specific rule files; alternative to a monolithic CLAUDE.md.
paths (frontmatter) — List of globs in a .claude/rules/ file; the rule only loads on matching files.
/memory — Command showing the loaded memory files; first diagnostic tool.
Slash command — Reusable prompt: .claude/commands/ (project) or ~/.claude/commands/ (personal).
Skill — Folder .claude/skills/<name>/ with SKILL.md and frontmatter; invoked on demand.
context: fork — Frontmatter option running the skill in an isolated subagent.
allowed-tools — Frontmatter option restricting the tools usable during the skill.
argument-hint — Frontmatter option showing a parameter prompt when the skill is invoked without arguments.
Personal variant — Copy of a team skill in ~/.claude/skills/ under a different name, so as not to affect others.
Plan mode — Exploration and design mode before modification, for large tasks or architectural decisions.
Direct execution — Default mode for simple, well-scoped changes.
Explore (subagent) — Subagent isolating verbose discovery and returning a summary to the main context.
Input/output examples — Refinement technique: 2-3 concrete cases when prose is interpreted inconsistently.
Test-driven iteration — Write tests first, then iterate by sharing failures.
Interview pattern — Have Claude ask questions before implementing, to surface unanticipated considerations.
-p / --print — Non-interactive mode flag for pipelines; without it the job hangs.
--output-format json — JSON output parseable by the pipeline.
--json-schema — Schema enforced on the JSON output for structured findings.
Session isolation — Principle that an independent instance reviews better than the session that generated.
Going further
Next is Domain 4 — Prompt Engineering & Structured Output (20%), which deepens explicit review criteria, few-shot, structured output via tool_use and the multi-instance review mentioned here. For a panorama of real tools in the Claude Code and MCP ecosystem, our 40 Claude Code / MCP tools sheet is continuously updated.
If you want to certify a whole team — or set up Claude Code properly on a real repo (CLAUDE.md hierarchy, rules, skills, CI pipeline with independent review) — that's what nAIvigate Studio does in a Sprint.