1. CLAUDE.md hierarchy & precedence
CLAUDE.md files hold persistent instructions Claude Code loads automatically at session start. They exist at multiple levels, and more specific overrides more general on conflict — while all levels are loaded together:
| Level |
Location |
Scope |
Typical content |
| Enterprise / managed policy |
system-managed path (IT-deployed) |
whole org |
mandated policies |
| User (global) |
~/.claude/CLAUDE.md |
every project for this user |
personal preferences |
| Project |
<repo>/CLAUDE.md (checked in) |
everyone on this repo |
build commands, conventions, architecture notes |
| Local / subdirectory |
CLAUDE.md deeper in the tree, or CLAUDE.local.md (not committed) |
that subtree / just you |
area-specific or personal-only notes |
Precedence on conflict (the exam fact): enterprise policy wins over everything; then the more specific file wins — project overrides user for that repo; a subdirectory file refines the project file for its subtree.
Two design rules the exam rewards:
- Keep CLAUDE.md lean. It's loaded into context every session — every token spent here is spent on every task. Move rarely-needed detail into skills (loaded on demand) or docs.
- Project CLAUDE.md is a team artifact — check it in. Personal quirks go in the user file or
CLAUDE.local.md, not the shared one.
📊 Diagram — “CLAUDE.md precedence hierarchy with side notes” (a version appears earlier on this page)
2. .claude/rules/
Instead of one monolithic CLAUDE.md, .claude/rules/ holds multiple focused rule files (markdown) that are loaded alongside it. Use it to keep instruction sets modular — testing.md, api-conventions.md, security.md — easier to review, own, and update than one growing file.
Exam angle: "the team's CLAUDE.md has grown to thousands of tokens of mixed guidance; what's the best restructure?" → split into .claude/rules/ topic files; push task-specific procedures into skills so they only load when relevant.
3. The mechanism menu — the highest-yield table in this domain
"Which mechanism should the team use?" is the most common question shape in Domain 3. Learn this table:
| Mechanism |
Trigger |
Best for |
Key property |
| CLAUDE.md / rules |
Loaded automatically every session |
Always-relevant context: build commands, conventions, architecture |
Always in context (costs tokens every session) |
| Skill |
Loaded on demand when relevant (or invoked) |
Task-specific procedures & expertise: "how we do releases", document workflows |
Progressive disclosure — costs ~nothing until needed |
| Slash command |
User explicitly types /name |
Repeatable prompts a human kicks off: /review-pr, /write-tests |
Deliberate, parameterizable invocation |
| Hook |
Lifecycle event fires (PreToolUse, PostToolUse, ...) |
Guarantees: policy, blocking, logging, auto-format after edit |
Deterministic — always runs; not up to the model |
| MCP server |
Tools become available to the model |
Connecting external systems (Jira, DB, internal APIs) |
Extends capability, not instructions |
Fast selector:
- "Claude should always know X about this repo" → CLAUDE.md / rules
- "Claude should know how to do this kind of task well, when it comes up" → skill
- "A developer wants to run this workflow on demand" → slash command
- "This must happen every time, no exceptions" → hook
- "Claude needs to talk to an external system" → MCP
Distractor alert: options that put policy in CLAUDE.md ("add a rule saying never...") when the scenario demands a guarantee. CLAUDE.md is still prompt-space — probabilistic. Guarantees live in hooks and permissions.
📊 Diagram — “Decision tree for choosing CLAUDE.md, skill, command, hook, or MCP” (a version appears earlier on this page)
4. Hooks in Claude Code
Hooks are shell commands configured in settings (e.g. .claude/settings.json) that run at lifecycle events:
| Event |
Fires |
Canonical uses |
PreToolUse |
Before a tool call executes |
Block dangerous commands, require approval, validate inputs |
PostToolUse |
After a tool call completes |
Auto-run formatter/linter after edits, audit logging |
| Session / other events (start, stop, notification...) |
At session lifecycle points |
Setup, cleanup, notifications |
A PreToolUse hook can block the action (non-zero exit / deny decision) — that's what makes it enforcement rather than advice.
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [{ "type": "command", "command": "npx prettier --write \"$FILE\"" }]
}
]
}
}
Same principle as Domain 1: prompts guide, hooks enforce — here applied to a developer workflow ("code must always be formatted", "never run rm -rf", "log every Bash command").
5. Plan mode
Plan mode makes Claude Code research and propose before touching anything: it explores the codebase read-only, produces a plan, and only executes after you approve.
When it's the exam answer:
- Large or risky changes (migrations, refactors across many files)
- Unfamiliar codebases — force understanding before edits
- Any scenario emphasizing review before execution or stakeholder sign-off
Contrast: for a trivial single-file fix, plan mode is overhead — the exam expects judgment, not "always use plan mode."
6. Sessions: /compact, --resume, /clear
| Command |
Effect |
Reach for it when |
/compact |
Summarizes the conversation in place, freeing context while preserving key facts |
Long session, context nearly full, work continues |
/clear |
Wipes the conversation entirely — fresh start |
Switching to an unrelated task |
claude --resume (or --continue) |
Reopens a previous session with its history |
Interrupted work; picking up next day |
The Domain 5 crossover fact: compaction is summarization — it can lose detail. Decision-critical state (requirements, decisions made, file lists) should also live in durable files (a scratchpad, a TODO.md) so nothing depends on the summary being perfect.
7. Permissions & tool allowlists
Claude Code asks permission before sensitive actions; teams tune this in settings:
- Allowlists (
permissions.allow): pre-approve safe, frequent operations (e.g. Bash(npm test), Read) to reduce prompt fatigue.
- Denylists (
permissions.deny): hard-block specific patterns (e.g. Bash(rm -rf*), reading .env*).
--allowedTools (CLI flag): cap the tool surface for a run — essential in CI/headless where nobody is present to approve.
{
"permissions": {
"allow": ["Read", "Grep", "Glob", "Bash(npm test:*)"],
"deny": ["Bash(rm:*)", "Read(.env*)", "Read(**/secrets/**)"]
}
}
Exam framing: permissions are the Claude Code face of least privilege — the same principle as allowedTools for subagents (Domain 1) and minimal tool surface (Domain 2).
8. .mcp.json and configuration scopes
MCP servers are configured at three scopes; the file answers "who gets this server?"
| Scope |
Where |
Shared with |
Use for |
| Project |
.mcp.json at repo root, checked in |
Everyone who clones the repo |
Team-standard servers (issue tracker, project DB) |
| User |
user-level config (~/.claude…) |
Just you, across all projects |
Personal tooling |
| Local |
project-local, not committed |
Just you, this project |
Experiments, servers with personal credentials |
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
}
}
}
Two tested details:
- Scoped distribution: "the whole team needs the Jira server" → project-scope
.mcp.json, checked in. "Only I need it" → user/local scope. Committing a server that needs personal credentials → reference environment variables, never literal secrets in the file.
.mcp.json is configuration; the server's tools still flow through the same permission system as everything else.
9. Headless mode: claude -p for CI/CD
-p / --print runs Claude Code non-interactively: one prompt in, result out, exit. This is the building block for CI pipelines — and a guaranteed exam topic (Scenario S5 is entirely about it).
# Basic: run a task and print the result
claude -p "Review the diff in this PR for security issues" \
--output-format json \
--allowedTools "Read,Grep,Glob" \
--max-turns 20
# In a GitHub Action step
- name: AI review
run: |
claude -p "Summarize risky changes in this PR as markdown bullets" \
--output-format json > review.json
env:
ANTHROPIC_API_KEY }}
The flags that matter (and why the exam cares):
| Flag |
Purpose |
Reliability angle |
-p "<prompt>" |
Non-interactive run |
No human present — everything must be pre-configured |
--output-format json |
Machine-readable result envelope (incl. result text, cost, session id) |
Pipelines parse output — never scrape free text |
--allowedTools "..." |
Explicit tool allowlist for the run |
Nobody can approve prompts in CI → pre-authorize the minimum |
--max-turns N |
Cap agentic iterations |
Bound cost/time; a stuck run fails fast instead of hanging the pipeline |
| exit code |
Non-zero on failure |
Lets the CI step fail properly |
Headless mental model: interactive Claude Code relies on a human as the safety net; in CI the flags replace the human. Options that assume interactive approval prompts inside a pipeline are wrong by construction.
📊 Diagram — “Headless claude -p pipeline flow with guardrail flags” (a version appears earlier on this page)
10. Built-in tools
Claude Code ships with a standard toolset. Knowing which tool fits which job shows up in Scenario S4 (developer productivity) questions:
| Tool |
Does |
Prefer it over |
Read |
Read a file (incl. images/pages) |
Bash(cat ...) |
Write |
Create/overwrite a file |
shell redirection |
Edit |
Targeted string replacement in a file |
rewriting whole files for small changes |
Glob |
Find files by name pattern |
Bash(find ...) |
Grep |
Regex search across files |
Bash(grep ...) |
Bash |
Run shell commands |
— (use when there's no dedicated tool) |
Why dedicated tools beat Bash equivalents (exam rationale): they're individually permissionable (you can allow Read while denying Bash), parallel-safe, and produce structured results the harness can gate and audit. Bash is the escape hatch, not the default.
11½. Official exam-guide addenda (v1.0)
Specifics from the official task statements (Exam Guide v1.0, July 2026):
CLAUDE.md mechanics (TS 3.1). Three tested details beyond the hierarchy table: the @import syntax lets a CLAUDE.md reference external files (each package's file imports just the standards it needs — modularity without duplication); the /memory command shows exactly which memory files are loaded — the diagnostic for "Claude behaves differently for teammate X" (classic root cause: the instruction sits in someone's user-level ~/.claude/CLAUDE.md, which version control never shares); and .claude/rules/ is the modular alternative to a monolithic file.
Path-scoped rules (TS 3.3). Rules files support YAML frontmatter with a paths: field of glob patterns — the rule loads only when editing matching files:
---
paths: ["**/*.test.tsx", "terraform/**/*"]
---
This beats subdirectory CLAUDE.md files when a convention follows a file type scattered across directories (test files, IaC files), and it saves tokens by not loading irrelevant rules.
Skill frontmatter (TS 3.2). SKILL.md supports three tested options: context: fork — run the skill in an isolated sub-agent context so verbose output (codebase analysis, brainstorming) doesn't pollute the main conversation; allowed-tools — restrict tool access during skill execution; argument-hint — prompt the invoker for required parameters. Commands split the same way as everything else: .claude/commands/ = project/shared, ~/.claude/commands/ = personal.
Plan mode's helper (TS 3.4). The Explore subagent isolates verbose discovery output and returns summaries — the context-preserving way to do large read-only investigation phases.
Iterative refinement (TS 3.5) — a topic of its own on the exam. Four techniques: (1) when prose instructions produce inconsistent results, give 2–3 concrete input/output examples — the single most effective clarifier; (2) test-driven iteration — write the test suite first (behavior + edge cases + performance), then iterate by sharing test failures; (3) the interview pattern — have Claude ask questions before implementing in unfamiliar domains (surfaces cache invalidation, failure modes you didn't think of); (4) fixes that interact go in one detailed message; independent fixes iterate sequentially.
CI specifics (TS 3.6). --output-format json pairs with --json-schema to enforce the findings structure, not just request it. Re-running review after new commits? Include the prior findings and instruct "report only new or still-unaddressed issues" — that's the duplicate-comment fix. Test generation in CI? Provide the existing test files so it doesn't regenerate covered scenarios. And the same-session generator is a weak reviewer of its own code — use an independent review instance (cross-ref: page 03 §7).
Built-in tool fallback (TS 2.5). When Edit fails because the anchor text isn't unique, the reliable fallback is Read (full file) + Write — not retrying Edit with more context. Explore codebases incrementally: Grep for entry points → Read to follow imports → trace flows; don't read everything upfront.
