Domain 2 · Claude Code Configuration & Workflows (20%)

This one tests the full configuration surface of Claude Code once you stop treating it as your personal assistant and start treating it as a team platform: memory files, skills, slash commands, hooks, settings, permissions, MCP wiring, headless/CI usage, and how it all relates to the Agent SDK.

At a glance

CLAUDE.md — the memory hierarchy

🧭 Your seat at the table: Claude Code ships with the harness pre-built — so your architect's job moves up a level: writing the standing stage. CLAUDE.md is you setting context and rules once so every future session inherits them; skills are you packaging expertise; hooks are you making rules deterministic; settings are you drawing the permission boundary. Domain 2 is the domain where "configuring a tool" and "architecting a system" turn out to be the same activity.

flowchart TD
  E[Enterprise managed policy] --> U[~/.claude/CLAUDE.md — user]
  U --> P[repo/CLAUDE.md — project, checked in]
  P --> N[subdir/CLAUDE.md — nested, loaded on demand]
  N --> C[Session context]

At the very top sits the Enterprise managed policy — a managed settings file an organization's IT pushes down to every machine. It loads automatically, and nothing a user, project, or CLI setting does can override it (the walkthrough below shows it in action).

• Loaded automatically at session start. For memory, all the loaded files are combined as instructions, with the narrower-scope file (project, then nested) intended to guide behavior for its part of the tree — it's contextual weighting, not the hard, deterministic > chain that governs settings/permissions (that strict chain is spelled out under Permissions below). When two instructions genuinely conflict, the more specific one usually wins, but treat memory as layered guidance rather than a rigid override table.
• Content that belongs there: build/test commands, architecture conventions, style rules, repo etiquette — durable instructions, not task prompts.
• Keep it short and imperative; every token loads into every session. Link out with @path imports — an @ followed by a file path (e.g. @docs/architecture.md) tells CLAUDE.md to pull that file's contents in on demand — rather than paste long docs inline.
• # at the start of a message adds a memory quickly; /memory edits memory files; /init bootstraps a CLAUDE.md for a repo.

🎯 Scenario 2 (team code generation — one of the six scenarios) loves precedence questions: enterprise policy > project settings > user settings for permissions; for memory, project CLAUDE.md governs the repo while ~/.claude/CLAUDE.md follows the person. Shared standards → project file in git; personal preferences → user file.

🧭 Every layer here is a clickable real file below — the layers as real files.

Skills vs slash commands vs subagents — the discriminator

These three mechanisms — and the exact lines between them — are current as of mid-2026 — check current docs, because Claude Code's configuration surface keeps evolving under your feet.

🧭 Decode the official vocabulary: docs and exam say skills are “model-invoked” — that means the model chooses (it reads each skill’s description and decides one is relevant, exactly the way it picks a tool from tools[]), never that the model executes. The model has no hands here either: it selects, and Claude Code — the harness in your terminal — performs the invocation. Same division of labor as the tool-use handshake. Hooks complete the spectrum: nobody chooses at runtime — the harness fires them on events, deterministically.

🪤 Trap: "the team keeps pasting the same 20-line release-checklist prompt" → slash command. "The team wants Claude to know the deployment procedure whenever deploys come up" → skill. "Code review burns the main session's context" → subagent.

Skill frontmatter — the three options the exam names

SKILL.md files carry YAML frontmatter — the config block the harness parses, above the body the model reads (drill the term for the full anatomy). Three fields are tested by name:

Project skills live in .claude/skills/ (shared via git); personal variants go in ~/.claude/skills/ under a different name so they don't shadow the team's version.

Skill or agent? — packaging a procedure like “go live”

The discriminator above separates the mechanisms; this is the question you actually face: my team has a stage-it / ship-it / go-live procedure — skill or agent? The answer is a composition, not a choice:

---
name: go-live
description: Use when asked to ship, deploy to production, or "go live".
context: fork                 # the WHOLE procedure runs in a disposable context…
agent: general-purpose        # …executed by this agent (or a custom deploy agent with only Bash+Read)
allowed-tools: Bash, Read
---
1. Run `scripts/ship.sh "<message>"` and wait for it to finish.
2. Verify the live URL returns 200.
3. Report back ONLY: commit shas, deploy URL, and any failure verbatim.

Saying “ok, go live” now means: the model matches the description → Claude Code forks the agent → the checklist and all build noise live and die in that context → your session receives three lines. This repo now carries exactly this skill — kb:.claude/skills/go-live/SKILL.md — say “go live” in a session here and the ship runs forked. The anti-pattern is putting the procedure inside a deploy-agent's system prompt instead: it works via delegation, but the knowledge is locked in the executor — invisible to the main loop, unshareable with other agents, and drifting from the team's skill the day either is edited.

🧭 The same knowledge/executor split you already know: CLAUDE.md and skills carry what to do; agents carry who does it, where, with which tools. Compose, never duplicate.

.claude/rules/ — path-scoped conventions with glob frontmatter

When do rules load? .claude/rules/*.md is part of the MEMORY family: plain topic files load at session start, exactly like CLAUDE.md content — they are organization, not laziness. Adding paths: frontmatter is what makes a file conditional: it surfaces only when the files being worked on match the glob. So: split for tidiness → always loaded; split with paths: → loaded when relevant.

🧭 “Keep these standing rules” — where do they land? When you tell a session “from now on, always X”, that is a rule (memory), not a skill: the assistant writes it into ~/.claude/CLAUDE.md (global, every project) or the repo's CLAUDE.md / .claude/rules/ (project-wide), and the HARNESS loads it every session — nothing chooses it, it is simply always in context. A skill is the opposite contract: an on-demand procedure the model CHOOSES by description when relevant. Constraint you must never forget → rule. Procedure you sometimes run → skill.

A monolithic CLAUDE.md loads everything into every session. Two mechanisms shrink that:

• Topic files: split rules into .claude/rules/testing.md, api-conventions.md, deployment.md — organization without one giant file.
• Path-scoped rules: give a rules file YAML frontmatter with glob patterns — paths: ["terraform/**/*"] or paths: ["**/*.test.tsx"] — and it loads only when Claude edits a matching file. Irrelevant conventions stay out of context; token budget goes to rules that apply right now.

The discriminator the exam tests (this is a sample-question pattern): conventions tied to a file type spread across the whole tree (test files everywhere, React components in many folders) → glob-pattern rules, because directory-level CLAUDE.md files are directory-bound and can't follow a pattern. Conventions tied to one subtree → a nested CLAUDE.md works. Relying on Claude to "infer which section applies" from one big file → the wrong answer, every time it's offered.

Watch the merge happen — layered config, git-diff style

Two families, two different merge semantics — this is the visual that makes precedence stick. Left: each layer's file (weakest first). Right: the running effective config, every line badged by the layer that won; overridden values struck through.

flowchart TB
  subgraph SETTINGS [settings — per-key OVERRIDE, strongest wins]
    U1[user settings] --> M1{merge by key}
    P1[project settings] --> M1
    L1[settings.local.json] --> M1
    MP1[managed policy] -->|always wins| M1
    M1 --> E1[ONE effective value per key]
  end
  subgraph MEMORY [memory — UNION, all load together]
    E2[enterprise CLAUDE.md] --> M2{concatenate}
    U2[user CLAUDE.md] --> M2
    P2[project CLAUDE.md + rules/] --> M2
    N2[nested CLAUDE.md] -->|specificity wins at conflicts| M2
    M2 --> EF2[ALL lines in context]
  end

Settings — per-key override. Watch model change hands three times, permissions.deny arrive untouchable, and the allow list accumulate:

{"mode":"override","layers":[
 {"name":"user","file":"~/.claude/settings.json","entries":[
   {"k":"model","v":"claude-sonnet-5"},{"k":"permissions.allow[git]","v":"Bash(git status)"},{"k":"hooks.PreToolUse","v":"guard.sh"}],
  "note":"yours, every project — the weakest layer"},
 {"name":"project","file":"<repo>/.claude/settings.json","entries":[
   {"k":"model","v":"claude-opus-5"},{"k":"permissions.allow[test]","v":"Bash(npm run test:*)"}],
  "note":"committed — every teammate inherits"},
 {"name":"local","file":"<repo>/.claude/settings.local.json","entries":[
   {"k":"model","v":"claude-haiku-4-5"}],
  "note":"personal, gitignored — beats both below it"},
 {"name":"managed","file":"/Library/…/managed-settings.json","entries":[
   {"k":"permissions.deny[env]","v":"Read(.env*)"},{"k":"disableBypassPermissionsMode","v":"disable"}],
  "note":"IT's layer — nothing below can loosen it"}]}

Memory — union. Nothing is overridden; everything loads, and only an explicit conflict is resolved (most specific wins):

{"mode":"union","layers":[
 {"name":"enterprise","file":"/Library/…/ClaudeCode/CLAUDE.md","entries":[
   {"k":"org","v":"never paste customer PII"}],
  "note":"MDM-deployed, read-only"},
 {"name":"user","file":"~/.claude/CLAUDE.md","entries":[
   {"k":"style","v":"prefer uv for Python"},{"k":"ui","v":"zen-light theme by default"}],
  "note":"travels with YOU"},
 {"name":"project","file":"<repo>/CLAUDE.md","entries":[
   {"k":"tests","v":"npm run test:unit (never plain npm test)"},{"k":"style","v":"THIS repo uses poetry","conflicts":false}],
  "note":"travels with the repo — note style now has TWO lines loaded"},
 {"name":"nested","file":"<repo>/billing/CLAUDE.md","entries":[
   {"k":"billing","v":"ledger writes via postEntry() only"}],
  "note":"joins when working under billing/ — deepest wins where lines disagree"}]}

⚠️ That enterprise line — “never paste customer PII” — is advisory, like all memory: the rule and an accidental paste reach the model in the same context, so it cannot prevent exposure, only shape behavior after it. What prevents is deterministic and sits BEFORE the call: the PII boundary.

🧭 The exam discriminator hiding in these two pictures: settings produce ONE value per key (ask “who wins?”) while memory produces ALL the lines (ask “what's loaded — and which line is more specific?”). Skills and slash commands follow the memory family's shape — project and user versions coexist under different names; nothing overrides.

Beyond the standard mechanisms — the project-map pattern (a house invention)

Everything above CONDITIONS what loads: nested CLAUDE.md (by subtree), paths: rules (by file pattern). This pattern inverts the question: instead of conditionally loading more knowledge, always load a tiny index — a ~60-line file with one mermaid diagram of the project's spine plus a | Need | Location | lookup table — injected into the system prompt by the project launcher at session start.

The context math that makes it a real pattern and not a convenience: without the map, every “where is the deploy script?” costs a grep-read round trip — 2–6 tool turns, each returning output that lands in context and stays there. Ten questions ≈ thousands of tokens of one-shot search debris. The map is ~1.5K tokens, loaded once, answers all ten, and keeps exploration read-only. It also survives compaction better than search results do — an index compresses; transcripts of find output don't.

🧭 Say it in one line: rules load what the session should KNOW; the map loads what the session can FIND — pushed knowledge vs a pushed index that makes every later pull precise. It composes with, not replaces, the standard ladder — and pairs with a refresh skill so the map is regenerated whenever the structure drifts (a stale index is worse than none).

Plan mode vs direct execution — and the Explore subagent

Two execution postures, one decision rule:

• Plan mode — for tasks with architectural implications: large-scale changes, many files, multiple valid approaches, service-boundary decisions. Claude explores the codebase and designs an approach before committing to changes — preventing the costly rework of discovering dependencies mid-edit. Classic triggers: monolith→microservices restructuring, a library migration touching 45+ files, choosing between integration approaches.
• Direct execution — for well-scoped, well-understood changes: a single-file bug fix with a clear stack trace, adding one validation check. Plan mode here is ceremony.
• The combo is legitimate and tested: plan mode to investigate and design, then direct execution to implement the approved plan.
• The Explore subagent is the context-budget companion: it isolates verbose discovery (mapping a large codebase, tracing flows) in its own context and returns a summary — so a multi-phase task doesn't exhaust the main window on exploration output.

🎯 "Restructure the monolith — where do you start?" → plan mode, explore before changing (not "start editing and let boundaries emerge"). "Single bug fix with a stack trace?" → direct execution. "Discovery output is eating the context window?" → Explore subagent.

Hooks — deterministic control (the harness inside Claude Code)

Hooks are just shell commands that fire on lifecycle events, and they can do one of three things: observe, block (exit code 2, on supported events like PreToolUse), or run side effects (say, auto-format right after a write). The key difference from instructions: these are guaranteed by code, not politely requested in prose. Timing is everything here — a PreToolUse hook runs before the action and can veto it outright, but a PostToolUse hook runs after the thing already happened. It can format or test the file that was just written, but it can't un-write it.

Exit code 2 from a PreToolUse hook blocks the action and feeds stderr back to Claude — that's the enforcement loop.

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{ "type": "command",
                  "command": "python3 .claude/hooks/guard_bash.py" }]
    }],
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": "npx prettier --write \"$FILE\"" }]
    }]
  }
}

🎯 "How do you guarantee generated code is formatted / a dangerous command never runs?" — hooks (deterministic), never "add it to CLAUDE.md" (advisory). This distinction is repeatedly tested.

Permissions & settings precedence

• Tools require permission grants, listed in .claude/settings.json under permissions.allow / permissions.deny. Read the Tool(pattern:*) syntax as "this tool, but only for calls matching this pattern": Bash(npm run test:*) means the Bash tool restricted to commands starting npm run test, and * is the wildcard.
• To deny a pattern, put it in the deny list — Claude Code reads this file at startup and enforces it every session. For example, blocking Claude from reading a sensitive file:

{
  "permissions": {
    "allow": ["Bash(npm run test:*)"],
    "deny": ["Read(~/.zshrc)", "Read(.env*)"]
  }
}

• Precedence: enterprise managed policy > CLI flags > local project settings > shared project settings > user settings.
• --dangerously-skip-permissions exists for containers/CI — the exam answer is to use scoped allowlists instead wherever possible.
• Sensitive-file protection: deny-list secrets (.env, keys) so Claude cannot read them at all.

The layers as real files — annotated, clickable

💡 Everything above describes layers; this section lets you open them. The </> chips go to the claude-cookbooks repo (a live specimen of the hierarchy — it really ships nested memory and a .claude/ toolbox); locally they also open this machine's actual config in IntelliJ.

Memory (CLAUDE.md) — the full ladder, most specific wins

Enterprise memory — org-wide, MDM-deployed, read-only to users (static example — a personal machine won't have one, and that's checkable: ls "/Library/Application Support/ClaudeCode/")

# Acme Corp — engineering-wide Claude instructions   <!-- IT deploys this file; devs can't edit it -->
- Never paste customer PII into prompts; reference records by internal ID only.
- All generated code follows the Acme secure-coding checklist (wiki/SEC-101).
- Outbound network calls in examples must use the corporate proxy hostnames.

~/.claude/CLAUDE.md — user memory · personal · every project you open

# My global instructions            <!-- travels with YOU, not the repo -->
- Prefer uv for Python; never install a duplicate runtime.
- All web UIs default to the zen-light theme.

<repo>/CLAUDE.md — project memory · committed · every teammate's session

# acme-billing-agent                <!-- travels with the REPO -->
- Run tests with `npm run test:unit` (never plain `npm test` — it hits staging).
- Money amounts are integer cents everywhere. No floats. Ever.

<repo>/billing/CLAUDE.md — nested memory · loaded when working under billing/

# billing/ conventions              <!-- deepest file wins for this subtree -->
- Ledger writes go through `postEntry()` — direct INSERTs break replayability.

Specimens in the wild: cookbook:CLAUDE.md — root project memory · cookbook:skills/CLAUDE.md — nested memory for one subtree · cookbook:managed_agents/slack/CLAUDE.md — per-subproject memory, five of them in one repo.

Settings — the same key at three layers, and who wins

// /Library/Application Support/ClaudeCode/managed-settings.json — MANAGED POLICY (static example)
// Deployed by IT via MDM. WINS OVER EVERYTHING below — users cannot loosen it, only tighten.
{
  "permissions": {
    "deny": ["Read(.env*)", "Read(**/*.pem)",        // secrets unreadable org-wide
             "Bash(curl:*)", "Bash(wget:*)"],        // no ad-hoc exfil channels
    "ask":  ["Bash(git push:*)"]
  },
  "forceLoginMethod": "console",                     // org API billing — no personal claude.ai logins
  "forceLoginOrgUUID": "3f1a…-org-uuid",             // and only THIS org
  "disableBypassPermissionsMode": "disable",         // --dangerously-skip-permissions is dead here
  "env": { "HTTPS_PROXY": "http://proxy.acme.internal:8443" }
}

# CLI flags — one rung below managed policy, above every settings file (per invocation)
claude -p "run the release checks" \
  --model claude-opus-5 \
  --allowedTools "Bash(npm run test:*)"   # beats settings.json files for THIS run only

// ~/.claude/settings.json — USER: yours, every project
{
  "model": "claude-sonnet-5",                    // ← your personal default…
  "permissions": { "allow": ["Bash(git status)"] },
  "hooks": {                                      // deterministic control — fires regardless of prompts
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "./guard.sh" }]
    }]
  }
}

// <repo>/.claude/settings.json — PROJECT: committed, shared with every teammate
{
  "model": "claude-opus-5",                      // …overridden here for this repo…
  "permissions": { "allow": ["Bash(npm run test:*)"] }
}

// <repo>/.claude/settings.local.json — LOCAL: personal, gitignored, wins over both
{
  "model": "claude-haiku-4-5"                    // …and THIS one wins (managed policy & CLI flags aside)
}

Chain, strongest first: managed policy → CLI flags → settings.local.json → project settings.json → user settings.json — the table above, now with faces.

🪤 Specimen with drift — read critically: cookbook:skills/.claude/settings.json is a real in-the-wild settings file whose shape is legacy/nonstandard — contextFiles and projectInfo are not Claude Code settings keys, and its hooks lack the matcher/hooks nesting shown above. Perfect exam practice: spot what a validator would reject. The rest of the .claude/ toolbox there is canonical: cookbook:.claude/commands/review-pr.md — a slash command · cookbook:.claude/agents/code-reviewer.md — a subagent definition · cookbook:.claude/skills/cookbook-audit/SKILL.md — a skill.

Claude Code in CI/CD (scenario 5 — CI/CD automation — territory)

• Headless mode: claude -p "review this diff" --output-format stream-json in any pipeline; exit codes + JSON make it scriptable.
• GitHub Actions integration: @claude mentions on PRs/issues; the action runs Claude Code against the repo with a scoped token and your CLAUDE.md conventions.
• Architect concerns the exam probes: least-privilege tokens, pinning the action/model version, budget caps per run, treating Claude's PR feedback as advisory gate vs blocking gate (blocking requires deterministic criteria — tests/lint — not vibes), and audit logging of what the agent did.
• Headless + hooks + allowlists = the CI trust story: the agent can only run whitelisted commands, every action is logged, and formatting/tests run deterministically after edits.

Claude Agent SDK (scenario 1 & 4 — embedded agents & developer tooling — territory)

The Claude Agent SDK (which grew out of the Claude Code SDK) hands you that same agent harness as something you can call from code (TypeScript/Python): sessions, tools (Read/Write/Bash/Grep/Glob/WebFetch…), MCP connections, hooks, permissions, subagents — all of it, for building your own agents outside the terminal.

• Use the SDK when embedding an agent in a product (support bot, pipeline worker); use Claude Code interactively for development itself.
• The built-in tool suite (Read, Write, Edit, Bash, Grep, Glob) IS the "developer productivity tooling" of scenario 4 — know what each does and that Grep/Glob are read-only search while Bash is the powerful-and-gated one.
• Sessions maintain conversation state; --continue/--resume (CLI) and session ids (SDK) resume work.

Practice this domain

🎯 Done with Domain 2? Prove it: Claude Code (Q9–Q14) — commit to an answer before revealing. Locally, your picks are captured with timestamps and scored per section, so weak spots surface on the practice page's comfort tiles.