What this domain tests
3.1% of the exam — roughly 2 items out of 53. Together with Eval/Testing and Debugging (2.6%), this is the lightest end of the CCDV-F blueprint. Budget accordingly: Applications and Integration alone is 33.1%, more than ten times this domain's weight. If you have one evening left before the exam, it belongs to Domain 2, not here.
That said, this domain is unusually cheap to secure, because it tests recognition, not construction. The single skill written against it — "Claude Code Operation (3.1%)" — is a vocabulary list: core components, features, the CLAUDE.md hierarchy, repository initialization, settings.json configuration. Nothing in it asks you to design a system.
Minimum viable mastery is five things: name the five core components and what each does; explain the CLAUDE.md hierarchy and which file wins on conflict; distinguish headless from interactive mode; know the three session verbs (continue, resume, fork); know that settings scopes layer with the most specific winning.
One structural warning before the outline: Claude Code uses MCP servers and runs hooks, but on this blueprint MCP belongs to Domain 8 (Tools and MCPs, 10.6%) and hooks to Domain 7 (Claude Hooks, 1.0%). Study them there. This module treats them only as cross-references.
Theory outline
1. What Claude Code is
Claude Code is an agentic coding tool that runs in the terminal and operates directly on a repository: it reads files, edits them, runs commands, and drives version control, iterating in a tool-use loop rather than emitting a suggestion for you to paste. That is the distinction the exam cares about — a completion-style assistant proposes text; an agentic tool takes actions in your environment and observes the results.
It is available beyond the raw terminal (IDE integrations, desktop and web surfaces), and the same harness is exposed programmatically as the Claude Agent SDK. Hold that relationship as one sentence: Claude Code is the harness as a product; the Agent SDK is the harness as a library. Anything asking you to build an agent with it is Domain 1 (Agents and Workflows), not Domain 3.
2. Core components (guide list: Rules, Skills, Commands, Agents, Agent Memory)
The guide names five components. Learn them as five different answers to "how do I make this tool behave the way my team needs?"
| Component | What it is | The question it answers |
|---|---|---|
| Rules | The standing-instruction layer — persistent guidance and constraints that apply before any user turn | "What should always be true about how this agent behaves here?" |
| Skills | Packaged, named instruction sets the agent loads when a task matches | "How do I codify a repeatable procedure once and reuse it?" |
| Commands | Slash commands — built-in ones plus custom ones you author | "How do I invoke a specific workflow on demand?" |
| Agents | Named subagent definitions with their own prompt, tools, and model | "Who should handle this sub-task, with which permissions?" |
| Agent Memory | Persistence that survives beyond a single session | "What should the agent still know next time?" |
Two pairs are routinely confused on exam-style items:
- Skills versus Commands. A skill is matched — the agent reaches for it when the work fits its description. A command is invoked — a person types it. Same underlying idea (packaged instructions), opposite trigger. "Claude should automatically follow our deployment checklist whenever it deploys" is a skill; "the team wants a shortcut they can type before every release" is a command.
- Rules versus Agent Memory. Rules are authored policy: deliberate, reviewed, checked into the repo. Memory is accumulated state: what this agent learned or was told to remember. A stem about enforcing a team convention points at rules and configuration; a stem about not re-explaining the same context every session points at memory.
Skills, commands, and agents are all file-backed configuration living under a .claude directory — a project-level one in the repo and a user-level one in the home directory, following the same scope logic as everything else in this domain. Plugins bundle these components together for distribution, which is why the guide's Domain 2 lists plugin management alongside CLAUDE.md and settings.json.
3. The CLAUDE.md hierarchy
CLAUDE.md is the file that carries project instructions into every session. The exam tests the hierarchy, because that is where the interesting behavior lives.
| Layer | Typical location | Scope |
|---|---|---|
| User | The user's home .claude directory | Every project this person opens |
| Project | CLAUDE.md at the repository root, checked into version control | Everyone working in this repo |
| Directory-scoped | CLAUDE.md inside a subdirectory | Work touching that part of the tree |
Organizations that administer Claude Code centrally can also push instructions from a managed layer above all three; the settings side of that policy layer is enforced and cannot be overridden locally.
Three properties to hold:
They compose, they do not replace. A user-level file and a project-level file are both in effect. A nested file adds to, rather than erases, the root file.
More specific wins on conflict. When a subdirectory's instructions contradict the repository root's, the nearer file governs work in that subtree. This is the single most likely thing to be tested, usually as: "a monorepo's web package needs different conventions than the shared root — what's the right structure?" The answer is a subdirectory CLAUDE.md, not a longer root file full of conditionals.
Imports keep files small. A CLAUDE.md can pull in another file's contents by referencing it with an @-prefixed path. That is how a subdirectory file can be one line long and still carry a full convention document, and how shared instructions stay in one place instead of being copy-pasted into five packages.
Practical guidance the exam echoes: CLAUDE.md should hold durable, project-specific facts — build and test commands, architectural constraints, conventions that are not obvious from the code. It should not hold transient task state, and it should not restate what any competent reader would infer from the repository itself. Bloated instruction files are a context-engineering problem (Domain 6) as much as a configuration one.
4. Repository initialization
Initialization is the /init command: run inside a repository, it surveys the codebase and writes a starter project CLAUDE.md capturing structure, commands, and conventions it can detect. Three things the exam wants you to know about it — it is a bootstrap, not an oracle (a first draft to be edited); its output belongs in version control, because the point of a project-level file is that the whole team gets the same instructions; and re-running it later is a legitimate refresh path, not something to avoid.
5. settings.json configuration
Settings are JSON configuration files that control the agent's environment and permissions, and they follow the same layering logic as CLAUDE.md. The scopes a running session loads are user, project, and local — with an administrator-managed policy layer above all three that local configuration cannot override.
| Scope | Where it lives | Shared? |
|---|---|---|
| Managed policy | Administered by the organization | Enforced; not overridable |
| Local | A project-local settings file, typically git-ignored | Personal, this machine, this repo |
| Project | A settings file checked into the repository | Shared with the team |
| User | The home .claude directory | This person, every project |
Precedence runs managed policy > local > project > user: the narrower the scope, the higher it sits, with the org's policy layer above the whole stack. Command-line flags override the corresponding setting for a single session. Typical settings content: the model to use, environment variables to inject, hook definitions, permission rules (allow / ask / deny lists), status line configuration, and which plugins are enabled.
The permission model is the part most likely to surface in a scenario. Claude Code runs with an explicit permission posture rather than unrestricted access, selectable per session:
| Posture | Behavior |
|---|---|
| Default / manual | Prompts before consequential actions |
| Accept-edits | File edits proceed without prompting; other actions still gated |
| Plan | Investigates and proposes without making changes |
| Auto | A classifier decides per action instead of prompting the user each time |
| Bypass-permissions | Skips permission checks entirely — appropriate only for isolated sandboxes |
Auto-mode is named explicitly in the guide's skill description, so know what it is: a permission posture where the decision to allow an action is made automatically by a classifier rather than by a human prompt. It is not a smarter model, not a different agent, and not a way to grant new capabilities — it changes who approves, nothing else. Bypass-permissions is the genuinely unrestricted option, and the correct exam answer for it is always "sandboxed environments only."
6. Sessions, headless mode, and streaming mode
Session management. Three verbs, three intents:
| Intent | Mechanism |
|---|---|
| Pick up where I left off, here | Continue the most recent conversation in the current directory |
| Go back to one specific past conversation | Resume by session ID, or choose from a picker |
| Branch from a past conversation without overwriting it | Fork the session — resume, but write to a new session ID |
Forking matters when you want two divergent explorations from one shared baseline: both branches inherit the context up to the branch point, and neither contaminates the other. Sessions can also be named for later retrieval, and long sessions are managed in-flight with the compaction and clearing commands rather than by restarting blind.
Headless mode is the non-interactive entry point: pass the prompt with the print flag (-p), and Claude Code runs to completion, prints the result, and exits. That is what makes it scriptable — CI pipelines, git hooks, batch file processing, anything that cannot sit at a terminal answering prompts. Because no human is present, headless runs must carry permissions and context explicitly: allowed and disallowed tool lists, additional directories, system prompt additions, and settings are all passed in rather than assumed.
Streaming mode is the output shape available in headless runs. Output format options are:
| Format | Shape | Use |
|---|---|---|
| text | Just the final answer | Piping into another command |
| json | A single structured result object | Scripts that need metadata (cost, session ID, usage) alongside the answer |
| stream-json | Events emitted as they arrive | Long runs where you need progress, or a UI rendering intermediate steps |
There is a matching input format for feeding in a stream of messages rather than a single static prompt — the shape used when Claude Code is embedded as a subprocess inside a larger application.
Built-in versus custom slash commands. Built-ins cover the operational surface — initializing a repository, editing memory, compacting context, clearing context, resuming a session. Custom commands are authored as files in the commands directory of a project or user .claude folder and become available by name. Built-ins are part of the tool; custom commands are your team's workflows given a name.
7. Troubleshooting a Claude Code installation
Worth recognizing, because "Claude Code behaves strangely after a config change" is the most plausible scenario stem in a two-item domain. There is a safe mode that starts a session with customizations disabled — CLAUDE.md, skills, plugins, hooks, MCP servers, custom commands and agents — while administrator-managed policy still applies; if the problem disappears there, it came from your configuration rather than the model or the install. Paired with it is a health-check command (claude doctor) that inspects the installation. Disable customizations to isolate, then check install health: the same problem-origin-isolation discipline Domain 4 tests, applied to the CLI.
Worked problems
Problem 1. A monorepo has a root CLAUDE.md documenting shared conventions. The web package needs different testing conventions that would be wrong for the API package. What is the right structure?
A. Rewrite the root CLAUDE.md with conditional sections ("if working in web/, then …") B. Add a CLAUDE.md inside the web package directory carrying the web-specific conventions C. Move all conventions into settings.json, which supports per-directory overrides D. Maintain two repositories
Approach: The hierarchy is the answer to every "different rules for different parts of the tree" stem. A directory-scoped CLAUDE.md composes with the root file and takes precedence within its subtree — exactly the described need, with no duplication and no conditionals.
Why the others fail: A works but is the anti-pattern the hierarchy exists to eliminate; conditional instructions grow unboundedly and every package pays the context cost of every other package's rules. C confuses the two configuration files — settings.json carries permissions, environment, hooks, and model configuration, not prose conventions. D is a repository-architecture change to solve a documentation problem.
Answer: B
Problem 2. A team wants Claude Code to review every pull request automatically from CI, posting findings as a comment. Which operating mode fits?
A. An interactive session left running on a build server B. Headless mode: invoke with the print flag, pass the prompt and an explicit allowed-tools list, and capture structured output C. Plan mode, so nothing is modified D. Auto-mode, so no one has to approve anything
Approach: "From CI" means no human is present to answer a permission prompt or read a terminal. That is the definition of headless: one invocation, prompt in, result out, exit — with permissions and context passed explicitly because nothing can be assumed from an interactive setup. Structured output is what lets the pipeline parse the result and post it.
Why the others fail: A is not automation; an interactive session is a person at a keyboard. C names a permission posture, not an execution mode — plan mode is still interactive, and it answers a different question (whether changes are made) than the one asked (how it runs unattended). D likewise confuses posture with mode: choosing who approves actions does nothing about the fact that there is no terminal, no prompt delivery, and no way to capture output.
Answer: B
Problem 3. A developer added several plugins and edited both project and user settings this week. Today Claude Code starts behaving unexpectedly in every repository. What is the most efficient first diagnostic step?
A. Reinstall Claude Code B. Start a session with customizations disabled (safe mode) to see whether the behavior persists C. Delete the project CLAUDE.md D. Switch to a different model
Approach: "Every repository" plus "after config changes" points at the user-level or plugin layer, not at any one project. The efficient move is bisection: disable the whole customization layer in one step and observe. If the behavior disappears, it is configuration; if it persists, it is the install or the model — and only then does a health check or reinstall make sense.
Why the others fail: A is a heavy, slow action taken before the problem has been localized — and it will not help if the cause is a settings file, which reinstalling does not touch. C deletes real work based on a guess, and cannot explain behavior that appears in every repository. D changes a variable that has nothing to do with the described trigger.
Answer: B
Exam traps
- Confusing execution mode with permission posture. Headless (print) is how it runs — unattended, one shot, exits. Auto, plan, accept-edits, bypass are who approves actions. Stems mix these deliberately; a question about CI automation is answered by the first axis, a question about approval friction by the second.
- Assuming a nested CLAUDE.md replaces the root file. It composes with it and takes precedence only on conflict, within its subtree. "Overrides everything" and "is ignored unless the root imports it" are both wrong.
- Getting the precedence direction backwards. Narrower scope wins: local over project over user — with organization-managed policy above all three. An answer claiming user-level settings override project settings has the ladder upside down.
- Treating /init as one-time or authoritative. It writes a first draft to be edited and committed, and re-running it later is fine. Options describing it as a permanent lock-in or as something that must never be hand-edited are wrong.
- Believing auto-mode grants capabilities. It changes who approves an action, not what the agent can do or how well it does it. Any option framing auto-mode as unlocking tools, improving quality, or removing all restrictions is a distractor.
- Skills versus commands. Matched-by-the-agent versus invoked-by-a-person. If the stem says "automatically, whenever the task involves X," it is a skill; if it says "the team types it," it is a command.
- Answering a Claude Code question with MCP or hooks content. Both appear inside Claude Code, but on this blueprint MCP is Domain 8 and hooks are Domain 7. A Domain 3 item asks about operating the tool — components, configuration, sessions, modes.
- Bypass-permissions as a convenience. The only defensible answer for it is an isolated sandbox. Any option recommending it to reduce prompting friction on a real machine is wrong; the intended answer for that need is a narrower permission posture or explicit allow rules.