The domain guides teach the objectives; the confused-concepts guides teach the distinctions. This one teaches the specifics — the production patterns that show up as the correct answer in scenario questions and are easy to miss if you only read the high-level docs.
Every technical detail here was verified against official Anthropic and Claude Code documentation. Where the community's collective memory is wrong — and on a couple of points it is — this guide says so, because publishing a confident falsehood is worse than omitting a detail.
Independent, unofficial study material. No real exam questions are reproduced.
Tool design: leakage, focus, and PostToolUse normalization
The implementation-leakage trap. A tool's description is routing signal for the model, not documentation for an engineer. Putting backend detail in it — "queries the Postgres RDS instance via GraphQL" — is a classic wrong answer. The model doesn't need infrastructure to decide when to call a tool; it needs the user-facing capability and clear disambiguation. Leaked implementation detail adds noise and can misroute.
PostToolUse as a normalizer, not just a linter. Most guides show PostToolUse hooks running a formatter or test after a file edit. The deeper pattern the exam rewards: use a PostToolUse hook to normalize heterogeneous tool output before it re-enters the model's context — converting mixed timestamp formats (Unix epochs, locale strings) into a single ISO 8601 form, or trimming a 40-column query result down to the 3 columns that matter. Deterministic normalization lowers the model's cognitive load and prevents hallucinated interpretations.
PostToolUse (matcher: Edit|Write) -> format / lint / test the edited file
PostToolUse (matcher: <data tool>) -> normalize the tool's output before it
returns to context (timestamps -> ISO 8601,
drop unused columns, standardize units)Structured output: shape is not truth, and two myths to unlearn
Syntax compliance ≠ semantic accuracy. Strict tool use and output_config.format guarantee the output shape — valid JSON, required keys present, enum values legal. They do not guarantee the values are correct. A schema-valid extraction can still be wrong or fabricated. That's why schema design (nullable/optional fields, an "unknown"/"other" enum escape) plus few-shot boundary examples matter: they let the model represent "not present" instead of inventing a syntactically-valid lie. Guaranteeing structure is step one; preventing fabrication is a separate step.
The Interview (clarification) pattern. For high-ambiguity tasks, the strongest design is often not to guess. Instruct the agent to pause and ask a targeted clarifying question before acting — e.g., before building a caching layer, ask whether invalidation should be TTL-based or event-based. This trades a round-trip for a large reduction in assumption-driven errors, and it's frequently the correct answer when a scenario stresses ambiguous or under-specified requirements.
Context reliability: lost-in-the-middle and Case Facts
Lost in the middle. Models recall content at the very start and very end of a long context far more reliably than material buried in the middle. The mitigation the exam tests: place the most critical instructions, constraints, and synthesized state at the top or bottom of the prompt array — not in the middle of a long transcript — and trim verbose tool output before it accumulates.
Case Facts persistence beats blind summarization. To fit long conversations into finite context, systems compress older turns into summaries. The danger: summarization degrades exact values — "$32.40" becomes "about thirty dollars," "March 14, 2025" becomes "recently," a specific customer ID vanishes. Downstream tools need the exact values. The architectural fix is to extract case facts — IDs, amounts, dates, finalized decisions, authorization state — into an immutable block kept outside the rolling summary and re-injected into every prompt. Summarize the prose; never summarize the numbers.
| Long-context problem | Wrong fix | Right fix |
|---|---|---|
| Key instruction ignored mid-transcript | Repeat it more emphatically inline | Move it to the top/bottom of the context |
| Context filling with verbose tool output | Ask the model to ignore the noise | Trim/normalize output (PostToolUse) before it lands |
| Exact figures lost after summarization | Trust the summary | Persist case facts (IDs/amounts/dates) in an immutable block |
Escalation vs. review routing: the confidence nuance
This pair is genuinely subtle and easy to get backwards. Both involve "confidence," but they use different signals.
- Escalation (removing the agent from the loop): trigger on rigid policy — an explicit human request, a policy gap where the agent has no instructions, an irreversible/high-stakes action, or an inability to progress after N attempts. Do not escalate based on the model's self-reported confidence or sentiment analysis: LLMs hallucinate confidently, so self-reported confidence is an unreliable routing signal.
- Human review routing (extraction pipelines): do route by confidence — but calibrated, external confidence (extraction/field-level scores validated against labeled data), plus document characteristics and field ambiguity. This is not the model's self-graded "I'm 90% sure"; it's a measured, trustworthy score.
Claude Code deep cuts: isolation, forking, and headless CI
`context: fork` — running a skill in isolation. When a skill produces verbose intermediate output (a deep codebase scan), that output can pollute the main conversation. Add context: fork to the skill's SKILL.md frontmatter and it runs in an isolated subagent with no access to the main conversation history; only its synthesized result returns. Companion frontmatter: agent (which subagent type to use) and background (defaults to running in the background; set it to wait in-turn).
---
name: audit-codebase
description: Deep scan of the repo for policy violations
context: fork # run in an isolated subagent; main context stays clean
agent: Explore # optional: which subagent type drives it
---
Scan every module and return only a summarized findings report.Session forking vs. resuming. --resume <id> (or the SDK resume) continues the same session. Set forkSession: true (TS) / fork_session=True (Python), or the --fork-session CLI flag, alongside resume to branch a session: the SDK creates a new session ID seeded with a copy of the history, leaving the original independently resumable. Think git branch — explore an alternative without disturbing the original thread.
Headless / CI execution. Claude Code is a CI asset. For non-interactive pipelines: -p/--print runs headless; --output-format json (or stream-json) returns parseable output instead of prose; --json-schema '<schema>' validates that output against a schema (print mode). Bound cost with --max-budget-usd (stops when the spend cap is hit). Control autonomy with --permission-mode — valid modes are default, acceptEdits, plan, bypassPermissions, auto, and manual — and --dangerously-skip-permissions (equivalent to bypassPermissions) for locked-down CI runners.
claude -p "Review this PR for security issues" \
--output-format json \
--json-schema "$(cat review-schema.json)" \
--max-budget-usd 2.00 \
--permission-mode planCLAUDE.md is concatenated, not overridden. Every applicable level's content is combined into context, loaded broadest-to-most-specific: a managed-policy file (enterprise, at an OS system path, cannot be excluded) → user (~/.claude/CLAUDE.md) → project (./CLAUDE.md or ./.claude/CLAUDE.md, version-controlled) → local overrides, with subdirectory files pulled in on demand. So .claude/CLAUDE.md is the project level (not "enterprise"), and user memory loads before project — they merge rather than one silently winning.
Key takeaways
- 01Tool descriptions are routing signal — never leak backend/infra detail; keep the tool set small and focused.
- 02PostToolUse isn't just format/lint — use it to normalize/trim tool output (e.g. → ISO 8601) before it re-enters context.
- 03Strict/structured output guarantees shape, not truth — pair it with nullable/enum escapes and few-shot to prevent fabrication.
- 04Myth: the Batch API can't do tool use. It can (plus multi-turn). Choose batch vs sync on latency/blocking; 50% off, 24h window.
- 05Place critical info at the top/bottom (lost-in-the-middle) and persist Case Facts (IDs/amounts/dates) outside lossy summaries.
- 06Escalate on rigid policy, never the model's self-reported confidence; route review on calibrated (measured) confidence.
- 07context: fork isolates a skill in a subagent; forkSession+resume branches a session; headless CI uses -p/--output-format json/--json-schema/--max-budget-usd/--permission-mode.
- 08Precise facts: @import depth is FOUR hops; there's no dontAsk mode; CLAUDE.md levels are concatenated, not overridden.
Common mistakes
Fixing verbose/mis-formatted tool output with a longer prompt.
Normalize or trim it deterministically in a PostToolUse hook before it re-enters the model's context.
Assuming a schema-valid extraction is a correct extraction.
Schema guarantees shape only. Add nullable/optional fields and an 'unknown' enum so the model reports absence instead of fabricating.
Ruling out the Batch API because 'it can't do tool calls.'
It supports tool use and multi-turn. Decide by latency/blocking; use batch for high-volume, latency-tolerant work.
Summarizing conversation history and trusting the numbers afterward.
Extract Case Facts (IDs, amounts, dates, decisions) into an immutable block kept outside the rolling summary.
Escalating to a human based on the model's self-reported confidence.
Escalate on rigid policy triggers; reserve calibrated confidence scores for extraction review routing, not agent escalation.
Frequently asked
What exactly does context: fork do to a skill?
Adding context: fork to a SKILL.md's frontmatter runs the skill in an isolated subagent that has no access to the main conversation history; the skill content becomes the subagent's prompt and only its synthesized result returns to the parent. Companion fields are agent (which subagent type) and background (whether it runs in the background). It's the skill-level equivalent of subagent isolation — keep a noisy task's output out of the main context.
Is context: fork the same as forkSession?
No. context: fork isolates a skill's execution in a subagent (Claude Code frontmatter). forkSession (Agent SDK) / --fork-session branches an entire session — with resume, it creates a new session ID seeded with a copy of the history, leaving the original resumable. One isolates a task's context; the other branches a whole conversation.
How do I get schema-validated output from a headless Claude Code run?
Run with -p/--print, add --output-format json, and pass --json-schema '<schema>' so the printed output is validated against your schema. Bound spend with --max-budget-usd and set autonomy with --permission-mode (e.g. plan) for a CI runner.
Does user CLAUDE.md override project CLAUDE.md?
No — the levels are concatenated into context, not overridden. Loading goes managed-policy → user → project → local, with subdirectory files added on demand, so all applicable guidance is combined. Put team-shared, version-controlled rules in the project file and personal preferences in the user file.
What's the max depth for @import in memory files?
Four hops. Memory files can recursively import other files (relative or absolute paths) up to a maximum nesting depth of four. Community write-ups sometimes say five — that's incorrect.
Independent, unofficial study material. Not affiliated with, endorsed by, or authorized by Anthropic. Every example is original and written to teach the public exam objectives — no real exam questions are reproduced. Technical details reflect Claude, the Anthropic API, Claude Code, and MCP as of July 25, 2026; always confirm specifics against current official documentation.
Test yourself
Turn what you just read into answers you can check.