Claude Code configuration and workflows

Claude Code’s configuration is a filesystem, and the exam walks it layer by layer. Instructions — the guidance that shapes what Claude tries to do — live in CLAUDE.md files. Enforcement — the rules it cannot talk its way past — lives in settings.json, hooks and permissions. Two systems, two sets of file names, two different answers to “what happens when two layers collide”. Learn the collision rules; the exam asks little else.

01CLAUDE.md: the instruction hierarchy

CLAUDE.md is the guidance file Claude Code loads automatically at launch — project conventions, style rules, the map of the repository. It exists in a hierarchy of scopes: organisation-managed settings can install instructions company-wide; the user scope lives at ~/.claude/CLAUDE.md and follows you across projects; the project scope is ./CLAUDE.md at the repository root, committed and shared; and a project-local variant (CLAUDE.local.md, effectively deprecated) covers personal, uncommitted additions. When several layers speak, all of them load — they concatenate, not conflict; the more specific file simply appears later, where recency and specificity carry the argument.

Two rules from the CCDV-F treatment remain exam-current and worth verbatim memory. First: CLAUDE.md or AGENTS.md, never both by default — the presence of any project CLAUDE.md (even a CLAUDE.local.md) suppresses the AGENTS.md fallback, so a repository that relies on AGENTS.md goes quiet the day someone adds a stray CLAUDE.md. Second: guidance is not enforcement. A line in CLAUDE.md is advice the model reads and may weigh; a deny rule in settings is a wall. Scenarios that say “must never” are asking for the wall.

Modular organisation is the third act. CLAUDE.md supports imports — a line like @docs/conventions/frontend.md pulls another file in — so the root file becomes a table of contents and the per-topic files stay small and individually maintainable. That matters more than aesthetics: instruction files bloat context on every single launch (they are read every session), and a five-hundred-line monolith taxes every run to serve rules that apply to a fraction of the work. Small, imported, per-concern files are the examined answer to “our CLAUDE.md has become unmanageable”.

02settings.json: the enforcement hierarchy

Where instructions advise, settings decide. The settings hierarchy runs managed (organisation-managed, nothing overrides it) → command line (flags on this invocation) → project (.claude/settings.json, committed) → local (.claude/settings.local.json, personal, gitignored). The merge is per key: a higher layer wins only on the keys it actually sets, and list keys such as permissions.allow combine across layers rather than replace. The exam’s small print is precise: “Don’t ask again” approvals land in .claude/settings.local.json — and when Claude Code itself made the approval, it adds the gitignore entry for you. Settings hot-reload mid-session for permissions, hooks and environment variables — but the model setting is read at launch and applies next session. Managed settings are the wall behind the wall: nothing in your project outranks them.

03Custom slash commands and skills

A custom slash command is a markdown file that becomes a prompt template: put deploy-check.md in .claude/commands/ and /project:deploy-check expands to its contents. The mechanics the exam quotes: $ARGUMENTS injects whatever follows the command; frontmatter can declare allowed tools and a description; a line like !`git diff HEAD` runs the command and injects its live output before Claude reads the template; @file references pull file contents in. User-scope commands (~/.claude/commands/) travel with you; project-scope commands travel with the repository — same choice, same verbs, as MCP scopes.

A skill is the heavier, discoverable sibling: a directory with a SKILL.md whose frontmatter (name, description) is always loaded, while the body is read on demand — progressive disclosure, so a growing library costs context only when used. Skills can bundle scripts and reference files, which makes them the right shape for “the release procedure, with its three helper scripts, available whenever anyone mentions a release”. The precedence quirk is exam-ready: a skill beats a command file of the same name; your skill can replace a bundled command but not its aliases; plugin skills are namespaced (/plugin-name:skill-name) and never collide with yours.

04Path-specific rules and conditional loading

Not every convention applies to every file, and the exam’s phrase for the fix is conditional loading — rules that arrive only when the work touches their territory. The mechanisms, cheapest first. Permission rules are path-scoped: a rule like Edit(docs/**) governs edits only under docs/ — so a documentation agent can be allowed to write exactly there and nowhere else. Hooks match by tool (and matcher patterns on the tool name), and their code can inspect the paths a call touches — the enforcement tier of conditionality. And the instruction tier: modular CLAUDE.md imports let a subdirectory’s conventions live beside the code they govern, or arrive via a command or skill that loads them only for that job.

The architect’s framing the exam rewards: conditional rules are a context-and-enforcement budget. Path-scoped permissions give “may edit docs, may not edit src” as a wall, not a wish; path-aware hooks give “lint only what changed”; conditional instruction loading keeps the forty lines of API-contract rules out of every session that never opens an API file. The wrong answers in this area are always unconditional: bigger CLAUDE.md files that apply everywhere, or manual review instead of a scoped rule.

05Plan mode versus direct execution

Claude Code runs in permission modes, and the exam’s comparison is plan mode versus direct execution. In plan mode the agent researches read-only — it can explore, grep, read, reason — but it executes nothing that changes state; at the end it proposes a plan, and you approve it before a single edit happens. Direct execution just works, asking permission at the usual gates. Shift+Tab cycles the modes interactively; headless runs select behaviour with --permission-mode.

The exam wants the choosing rule, not the keystroke. Plan mode earns its overhead when the task is large, the codebase unfamiliar, the change pattern unclear, or the blast radius scary — the expensive mistakes happen in the first ten minutes, and plan mode is how you buy review of those ten minutes before they touch anything. Direct execution wins for small, well-understood, low-stakes changes where a planning round-trip is pure latency. Note the architectural kinship: plan-then-execute is a workflow — a designed checkpoint between phases — exactly the HITL insertion point from Domain 1, wearing a keystroke.

06Iterative refinement: checkpoints, /clear, /compact

Real sessions wander: three wrong attempts, a tangent, a context full of stale reasoning. Claude Code’s refinement toolkit has three distinct instruments, and the exam tests that you know they are not interchangeable. Checkpoints and rewind: every session takes checkpoints, and rewinding (the double-Esc menu) restores both the code and the conversation to a chosen point — the “that approach was wrong, take me back” move; it is undo, not forgetting. /clear wipes the context and starts an empty conversation in the same session — the right move when the old reasoning is polluted but the work stands (after a big merge, a finished subtask, a debugging session that turned into archaeology). /compact summarises the conversation and continues with the summary — the right move when the thread is still useful but the window is filling (a mid-sized fix whose history has value at one-tenth the size). /compact takes optional instructions about what to preserve.

The distinction the exam keeps probing: compacting preserves a distilled thread; clearing severs it; rewinding travels back along it. A scenario’s verb chooses the tool — “keep going but the window is huge” → /compact; “start the next task clean” → /clear; “undo that whole approach including the edits” → rewind. Around these sit the habits of progressive refinement: work in small verifiable steps, run the tests between them, checkpoint before the risky move — the same ladder as Domain 1’s budgets: correct the scope, not the ceiling.

07Claude Code in CI/CD

The last subdomain is unattended operation — Claude Code with nobody at the keyboard. The headless shape: claude -p "prompt" runs one prompt to completion without the interactive UI, and --output-format json (or stream-json) emits machine-readable results — cost, duration, session identifiers, the works — so your pipeline can parse the outcome, post it as a comment, attach it to the PR. Exit code 0 on success means shell branching just works: the step after “claude -p” runs only when Claude succeeded.

Permissions headlessly are the same system with no human at the gate: --allowedTools takes permission-rule syntax — Bash(git commit:*), not just Bash — and --permission-mode sets whole-session behaviour (acceptEdits auto-accepts file edits; plan forces the read-only research mode). For reproducible runs, --bare starts a minimal session that skips the auto-discovered extras — no hooks, skills, subagents, plugins, MCP servers or CLAUDE.md — with configuration then arriving explicitly via --settings, --mcp-config or --append-system-prompt. That is the CI answer the exam wants: the same machine every time, no developer’s laptop leaking in, provenance of every rule visible in the command.

The architect’s checklist for CI follows by composition of everything above: project-scoped MCP servers (.mcp.json) so the pipeline shares the exact tools the team does; committed CLAUDE.md and settings so guidance and enforcement travel with the clone; explicit --permission-mode and --allowedTools so the blast radius of an unattended run is a decision, not an accident; parsed JSON output wired to the pipeline’s verdict; and the audit story — non-interactive runs are exactly the runs someone will later ask to justify.

08The traps

• —“Put it in CLAUDE.md so it’s enforced.” CLAUDE.md advises; it does not enforce. “Must never” needs settings/permissions or a hook — a wall, not a wish.
• —“Delete AGENTS.md, we use CLAUDE.md anyway.” The dangerous direction is the reverse: adding a CLAUDE.md silences an AGENTS.md the repository was quietly relying on.
• —“/compact before starting the next task.” Wrong instrument — a new task wants /clear (sever the thread); compact is for continuing the same one with less baggage.
• —“Settings.local.json is the team baseline.” It is personal and gitignored. Team baselines are committed: .claude/settings.json and project CLAUDE.md.
• —“Plan mode wastes time; we trust the agent.” Plan mode is the review you buy before the blast radius exists — the exact checkpoint unattended pipelines must design in.
• —“Use --allowedTools Bash so it can commit.” Too broad: the flag takes permission-rule syntax, and Bash(git commit:*) scopes the permission to the exact command. Unscoped permissions are how unattended runs become incidents.