CCDV-F Domain 3: Claude Code

CLAUDE.md is Claude Code's persistent context file — project or user instructions that get loaded automatically rather than pasted into every prompt. It is not a single flat file: Claude Code loads a CLAUDE.md hierarchically, and it also picks up a CLAUDE.md per subdirectory as you work in different parts of a repo. A monorepo can carry a root CLAUDE.md with org-wide conventions plus a packages/api/CLAUDE.md with API-specific notes, and both apply when you're working inside packages/api.

settings.json is a separate axis: it controls permissions, hooks, and tool behavior rather than prose instructions, and it is layered across multiple files with a strict precedence order. When two settings files disagree, the higher layer wins outright — it is not a merge of "most permissive" or "most restrictive", it's a strict override by source.

Claude Code's permission mode governs whether an action (a file write, a shell command, an MCP tool call) proceeds without asking. There are several modes, and the exam expects you to know the practical difference between them, not just the names.

bypassPermissions still exists and still means what it always did — zero checks — but it's explicitly scoped to sandboxed, non-root automation contexts (CI containers, ephemeral VMs), not something you'd reach for on a personal workstation now that auto covers that use case with a review layer intact.

Permission modes and CLAUDE.md instructions both operate at the level of the model's judgment — even a well-instructed model can misjudge a case. Hooks are different in kind: they are code-level, deterministic checks that run at defined lifecycle points, independent of what the model decides to do. This distinction — prompted behavior versus enforced behavior — is the core concept the exam is testing under "Hooks."

• Session-level: SessionStart, SessionEnd — fire once per session.
• Per-turn: UserPromptSubmit, Stop — fire around each conversational turn.
• Tool-loop-level: PreToolUse, PostToolUse, PermissionRequest — fire around individual tool calls, the finest-grained and most commonly used tier.
• Additional events for subagent/task lifecycle, MCP activity, and file-watch triggers.

A hook handler can be a command (run a script), an http call, an mcp_tool invocation, a prompt (ask the model something), or an agent (dispatch a subagent). Critically, a hook can block an action outright — either by exiting with status code 2, or by returning a JSON payload with a permissionDecision field — and that block is enforced by the harness, not negotiated with the model. A CLAUDE.md instruction saying "never commit to main" is a strong nudge the model will usually follow; a PreToolUse hook that rejects git commit on main with exit code 2 is a wall.

Custom slash commands used to be their own separate mechanism. That has changed: custom slash commands have been merged into Skills. A file at .claude/skills/<name>/SKILL.md now creates a /<name> command directly — there is no longer a separate, parallel commands system to learn.

The detail worth internalizing for the exam is when a Skill's content enters context. CLAUDE.md content is loaded up front and stays resident for the whole session — every turn pays its token cost, whether or not it's relevant to what you're currently doing. A Skill's body, by contrast, loads on demand, only when that skill is actually invoked. This is a context-budget distinction, not just an organizational one.

Subagents are defined in Markdown files with YAML frontmatter — .claude/agents/*.md for project-level agents, ~/.claude/agents/*.md for personal ones available across projects. The frontmatter specifies name, description, a tools allow/deny list, model, permissionMode, and optionally isolation: worktree to give the subagent its own git worktree.

The detail the exam expects precisely: a subagent gets a fresh, isolated context by default — it does not inherit the conversation that spawned it, only the task it was given. That is the opposite of a "fork," which inherits the full parent conversation history and branches from there. Confusing these two is an easy exam trap: dispatching a subagent to "go check something" without giving it the necessary background will fail silently, because it genuinely doesn't have that background — it isn't lazily choosing to ignore it.

• Subagent: fresh context, defined by a name/description/tools/model file, good for isolating noisy or exploratory work from the main thread.
• Session resume: continues the exact prior context, same thread.
• Session fork: branches from a point in history into a new session, leaving the original untouched — useful for trying an alternative approach without losing the main line of work.

Repo init is the documented workflow where Claude Code bootstraps a CLAUDE.md for a new or unfamiliar repository — it explores the codebase and captures build/test commands, conventions, and architecture notes, so a future session doesn't have to rediscover them from scratch. It's the recommended first step on any repo that doesn't already have a CLAUDE.md.

Headless (non-interactive) mode runs Claude Code as a single command rather than an interactive session — this is the mechanism for using it inside CI pipelines and scripts. The basic form is claude -p "<prompt>", with --output-format text|json|stream-json controlling how the result is emitted for a calling script to parse.

claude -p "Run the test suite and report failures" \
  --output-format json \
  --bare \
  --allowedTools "Bash(npm test)" \
  --permission-mode dontAsk

--bare skips auto-discovery of hooks, Skills, and MCP servers — it's the flag that makes a CI run fast and deterministic, since the run isn't picking up whatever happens to be configured in the environment it executes in. --allowedTools combined with --permission-mode dontAsk scopes exactly which tools may run without a prompt, which is what makes headless mode safe to run unattended: nothing outside the explicit allowlist executes.

{
  "permissions": {
    "defaultMode": "auto",
    "allow": ["Bash(npm test)", "Bash(npm run lint)"],
    "deny": ["Bash(git push --force*)"]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "./.claude/hooks/block-main-commits.sh" }
        ]
      }
    ]
  }
}