Claude Code Training

Review & instructor view

Source coverage, open issues, and ledger entries for all ready chapters.

Open issues

Open Issues

DateChapterIssueSeverityOwnerStatus
2026-06-061PDF page numbers in the source ledger are based on PDF-page positions from pdftotext form-feed boundaries, not printed book page numbers. Cross-check against the printed book if exact pagination is required.Lowneeds reviewOpen
2026-06-0611~~Not yet extracted or authored.~~ Resolved 2026-06-16 — Chapter 11 built; all 11 chapters now ready (course complete).——Closed
2026-06-134Content-accuracy re-audit complete (lesson/quiz/ledger were already correct; training-output mirror + ledger drift table patched). Route renders at /chapters/04-chapter-04 (HTTP 200, headless markers pass). Interactive browser check still pending — quiz submit-without-reload and sidebar/TOC scroll-spy not yet eyeballed (Chrome MCP not connected).Lowneeds reviewOpen
2026-06-135Chapter 5 built end-to-end (lesson, quiz, source ledger, training-output mirror, course.json → ready). Facts verified against canonical Anthropic + GitHub docs before authoring; book drift corrected and propagated across all four artifacts (action @v1 not @beta; branch claude/issue-<number>-<timestamp>; "Claude Code" not "Tag Claude"; lowercase .yml; four-event on: block; "Claude Agent SDK"; default push-branch+PR-link/no-auto-merge; anthropics/claude-code-action/examples + teams blog instead of the dead anthropics/skills/actions link). Dev server restarted (PIDs 55164/39396 stopped, fresh npm run dev on :4321) so the new ready route registers. Route renders at /chapters/05-chapter-05 (HTTP 200; 4 SVGs/4 figcaptions, 0 escaped SVG, 6 quiz questions, passingScore present, no AstroError). Interactive browser check still pending — quiz submit-without-reload and sidebar/TOC scroll-spy verified only via headless HTML markers (Chrome MCP not connected); ask user to eyeball.Lowneeds reviewOpen
2026-06-135Practical exercise Track A requires a GitHub repo the learner administers + a Claude subscription or API credit (real cost). Track B (local claude -p headless lab, no GitHub) is provided as the everyone-can-do-it path that reproduces the break-then-fix finding. Flag for facilitators scheduling the session.Lowneeds reviewOpen
2026-06-146Source PDF 06-chapter-06.pdf is image-only — no text layer (pdftotext -layout and pypdf both returned 0 chars; pages carry 16–21 embedded images each). pdftoppm/tesseract/ghostscript not available locally. Extracted by installing PyMuPDF and rendering all 16 pages to PNG at 150 DPI under work/ch6-pages/, then transcribing visually into extracted-chapters/06-chapter-06.md. No .txt mirror. Page markers are PDF-page indices, not printed book pages. The book's figures are screenshots (not reproduced); Fig 6.4's baked-in diagram labels were partly [unclear] and are not relied on. Cross-check the printed book if exact wording/pagination is needed. Future chapters (7–11) may also be image-only — same fallback applies.Lowneeds reviewOpen
2026-06-146Chapter 6 built end-to-end (lesson, quiz, source ledger, training-output mirror, course.json → ready, estimatedMinutes 115). Facts verified against canonical Anthropic docs before authoring — book found largely current (/plan is valid; explore-plan-code-commit, worktrees, subagents/agent-teams all confirmed). Additions/renames recorded in the ledger Drift table: plan-mode entry enriched with Shift+Tab cycle and --permission-mode plan (book teaches /plan only); Git worktrees named (claude --worktree) as the isolation fix the book describes-but-defers; the three "multi-agent" senses disambiguated (terminal instances / subagents / agent teams). Dev server restarted (stopped pid 58516/58548, fresh npm run dev on :4321) so the new ready route registers. Route renders at /chapters/06-chapter-06 (HTTP 200; 3 SVGs/3 figcaptions/3 figures, 0 escaped &lt;svg, quiz markup + passingScore present, no AstroError; <table> count matches the shipped Ch5 baseline; homepage lists Ch6 ready, Ch7 still 404/pending). Interactive browser check still pending — quiz submit-without-reload and sidebar/TOC scroll-spy verified only via headless HTML markers (Chrome MCP not connected); ask user to eyeball.Lowneeds reviewOpen
2026-06-146Practical exercise uses a framework-free static sandbox (~/cct-ch6-lab/: index.html + styles/hero.css + styles/cards.css) instead of the book's Next.js HookHub, so it needs no npm/Node and no accounts — runs in the room for everyone. Part 3 (worktrees) uses claude --worktree; verify the flag/behavior at code.claude.com/docs/en/worktrees before delivery in case it changes.Lowneeds reviewOpen
2026-06-145Accuracy re-audit (independent critique) verified against current official docs — softened several over-claims across all four artifacts: workflow YAML is now representative, not canonical (docs show multiple examples; inline basic workflow has 2 events, examples/claude.yml has 4); branch taught as "a separate branch under the configurable claude/ prefix, not main" (the claude/issue-<number>-<timestamp> form is the configurable default template, not a guaranteed suffix); gh reframed as useful-not-required for /install-github-app (only repo-admin is required); the two-template chooser + claude-code-review.yml framed as book-era (current /install-github-app sets up App + @claude claude.yml; PR review is copied from pr-review-*.yml examples); added a dated June-15-2026 subscription Agent SDK credit caveat. Drift block in CLAUDE.md corrected and AGENTS.md regenerated as a faithful (un-mangled) copy of CLAUDE.md. Quiz JSON re-validated; page re-renders HTTP 200.Lowneeds reviewOpen
2026-06-147Source PDF 07-chapter-07.pdf is image-only — 57 pages, no text layer (pdftotext/pypdf returned 0 chars). Extracted by rendering all 57 pages to PNG at 150 DPI with PyMuPDF into work/07-chapter-07-pages/ and transcribing visually (3 parallel subagents, merged) into extracted-chapters/07-chapter-07.md. No .txt mirror. Page markers are PDF-page indices, not printed book pages. Book figures are screenshots (not reproduced; the three lesson diagrams are original SVGs). Cross-check the printed book if exact wording/pagination is needed.Lowneeds reviewOpen
2026-06-147Chapter 7 ("Working with Claude Code Subagents") built end-to-end (lesson, quiz, source ledger, training-output mirror, course.json → ready, estimatedMinutes 120). Facts verified against canonical Anthropic docs + engineering posts before authoring — book found largely current on the subagents surface. Two genuine corrections propagated across all four artifacts: (1) the Infinite Agentic Loop creator is IndyDevDan (GitHub disler, agenticengineer.com), not the book's "IndieDevDan / IndieDev.com", and it's a community pattern, not an official Anthropic feature; (2) the Agent tool is the current name (book/infinite.md say "Task tool"). Completions/softenings also recorded in the ledger Drift table (12 rows): broader 5-level scope hierarchy beyond project/user; grown frontmatter schema (disallowedTools/permissionMode/mcpServers/isolation: worktree/color/…); tools as a genuine allowlist vs a Skill's allowed-tools grant; model defaults to inherit; built-in Explore/Plan agents; three invocation methods (book's "slash command" softened); 200K context softened; canonical code.claude.com host; the book's non-canonical LangGraph model id not reproduced; ~90.2%/~4×/~15× figures soft-worded as "internal evaluation." Cross-artifact grep audit clean (no stray "IndieDev"/"Task tool" as current; extract correctly retains book verbatim). Dev server restarted (stopped PIDs 58004/52708, fresh npm run dev on :4321) so the new ready route registers. Route renders at /chapters/07-chapter-07 (HTTP 200; 3 SVGs/3 figures/3 figcaptions, 0 escaped &lt;svg, 6 quiz-question blocks + passingScore, no AstroError; homepage "7 of 11 chapters ready"; Ch6→Ch7 pager; Ch8 still 404/pending). Interactive browser check still pending — quiz submit-without-reload and sidebar/TOC scroll-spy verified only via headless HTML markers (Chrome MCP not connected); ask user to eyeball.Lowneeds reviewOpen
2026-06-147Practical exercise uses a framework-free, stdlib-only Python sandbox (~/cct-ch7-lab/: prices.py/auth.py/slugify.py, each with a planted defect) instead of the book's Next.js + Infinite-Agentic-Loop Hero swarm, so it needs no npm/Node, no accounts, and no swarm-sized token spend — runs in the room for everyone while teaching the same create→shape→parallelize skills.Lowneeds reviewOpen
2026-06-158Source PDF 08-chapter-08.pdf is image-only — 39 pages, no text layer (image-only check returned 0 chars). Rendered all 39 pages to PNG at 150 DPI with PyMuPDF into work/08-chapter-08-pages/ and transcribed visually into extracted-chapters/08-chapter-08.md. Mixed-fidelity extract: code/commands/YAML/JSON/paths/keys are verbatim; explanatory prose is captured as faithful summaries (to avoid reproducing a copyrighted chapter at length). No .txt mirror. Page markers are PDF-page indices, not printed book pages. Book figures (screenshots/illustrations) not reproduced (the two lesson diagrams are original SVGs). Re-open page images for exact sentence wording.Lowneeds reviewOpen
2026-06-158Chapter 8 ("Creating and Customizing Output Styles") built end-to-end (lesson, quiz, source ledger, training-output mirror, course.json → ready, estimatedMinutes 115). Facts verified against canonical Anthropic docs before authoring — output-styles & statusline pages fetched directly. Central correction (Chapter-5-magnitude): the book's primary command /output-style was deprecated v2.1.73 and removed v2.1.91 → selection is now /config → Output style or the outputStyle setting; propagated across all four artifacts. Other drift in the ledger Drift table: built-ins now include Proactive (book lists 3); keep-coding-instructions (default false) is the SE-instructions escape hatch the book omits — lesson built around it; full frontmatter (name/description/keep-coding-instructions/force-for-plugin) + managed-policy scope; output-style appended to the system prompt, read once at session start; the comparison table (output style vs CLAUDE.md vs --append-system-prompt vs subagents vs Skills); status-line field is output_style.name (nested — book's bare-string read corrected); richer status-line JSON schema; project-scope settings valid (book uses global ~/.claude/settings.json); python3 works (book uses uv). The book's "team of specialized agents" reframed honestly (its metaphor vs documented subagents [stable] / agent teams [experimental, off by default behind CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS]). Dev server restarted (stopped PIDs 52152/65660, fresh npm run dev on :4321). Route renders at /chapters/08-chapter-08 (HTTP 200; 2 SVGs/2 figures/2 figcaptions, 0 escaped &lt;svg, 6 quiz-question blocks + passingScore, no AstroError; 6 tables = 1 lesson + 5 ledger; homepage "8 of 11 chapters ready"; Ch7→Ch8 pager; Ch9 still 404/pending). Quiz verified interactively via Playwright MCP (real browser): 6/6, inline feedback, no page reload, both diagrams render — stronger than prior chapters' headless-only checks. Cross-artifact grep audit clean.Lowneeds reviewOpen
2026-06-158Practical exercise uses a framework-free, stdlib-only sandbox (~/cct-ch8-lab/ with one tiny greet.py) instead of the book's Next.js repo, and runs the status line via plain python3 (book uses uv) configured at project scope (.claude/settings.json) so it's self-contained and reversible — no npm/Node, no accounts, no global-config edits. Ships two SVG diagrams (deliberate: the §6 multi-instance idea is carried by prose + analogy rather than a third diagram that might imply it's a first-class feature).Lowneeds reviewOpen
2026-06-159Source PDF 09-chapter-09.pdf is image-only — 30 pages, no text layer (image-only check returned 0 chars). Rendered all 30 pages to PNG at 150 DPI with PyMuPDF into work/09-chapter-09-pages/ and transcribed visually into extracted-chapters/09-chapter-09.md. Mixed-fidelity extract: code/commands/YAML/SKILL.md/paths/keys and Table 9.1 cells verbatim; explanatory prose summarized. No .txt mirror. Page markers are PDF-page indices. Table 9.1's first data row was partially cut at the top of page 28 in the render — the lesson's consolidated comparison is built from current docs, so this gap doesn't affect the lesson; cross-check the printed book for the exact first-row wording. Book figures not reproduced (the two lesson diagrams are original SVGs).Lowneeds reviewOpen
2026-06-159Chapter 9 ("Understanding Agent Skills") built end-to-end (lesson, quiz, source ledger, training-output mirror, course.json → ready, estimatedMinutes 115). Skills verified against canonical docs (skills page fetched directly) — book broadly current on the concept. An accuracy pass propagated 8 adjustments across all four artifacts (ledger Drift table): (1) selection follows the skill listing — description primary, when_to_use appended, first-paragraph fallback if no description — not "frontmatter only"; (2) a loaded skill body persists in-session (recurring cost; compaction re-attaches) — replaced "context goes away again"; (3) enforcement/fallback softened — skills are instructions not deterministic enforcement, recovery from a moved/failed script is a capability not a guarantee, use hooks for must-run steps; (4) exact token counts removed (qualitative "low upfront cost"); (5) hard launch dates removed/labelled background (skills are a cross-product agentskills.io open standard); (6) bundled-script path uses ${CLAUDE_SKILL_DIR} not a brittle relative path; (7) MCP defers tool definitions by default (tool search) — corrects the book's Table 9.1; (8) custom slash commands merged into skills. Source boundary tightened (engineering posts / open standard / LangChain / community marketplace = labelled background, not official behavior). Dev server restarted (stopped PIDs 39072/65032, fresh npm run dev on :4321). Route renders at /chapters/09-chapter-09 (HTTP 200; 2 SVGs/2 figures/2 figcaptions, 0 escaped &lt;svg, 6 quiz-question + passingScore, no AstroError; homepage "9 of 11 chapters ready"; Ch8→Ch9 pager; Ch10 still 404/pending). Quiz verified interactively via Playwright MCP (6/6, inline feedback, no reload, both diagrams render). Lesson + quiz clean of stale phrases; remaining matches only in ledger/training-output documenting the fixes.Lowneeds reviewOpen
2026-06-159Practical exercise uses a framework-free, stdlib-only sandbox (~/cct-ch9-lab/: a repo-brief skill + bundled stats.sh) instead of the book's Next.js HookHub + the mhattingpete/claude-skills-marketplace git-pushing skill — no npm/Node, no accounts. Teaches the same build → progressive-disclosure → deterministic-vs-AI arc. Distinct from Chapter 3's commit-summary skill exercise (which taught making a slash-command skill). Ships two SVG diagrams (the §5 primitive comparison is carried by a Markdown table + the workbench analogy).Lowneeds reviewOpen
2026-06-1510Source PDF 10-chapter-10.pdf is image-only — 43 pages, no text layer (image-only check returned 0 chars). Rendered all 43 pages to PNG at 150 DPI with PyMuPDF into work/10-chapter-10-pages/ and transcribed visually (one subagent) into extracted-chapters/10-chapter-10.md. Mixed-fidelity extract: headings/code/commands/paths/flags verbatim; explanatory prose summarized. No .txt mirror. Page markers are PDF-page indices; page 43 is Packt back-matter promo (not chapter content). Two needs review items: page 24's figure number rendered ambiguously as "Figure 10.2x" (inferred 10.24 because page 25 is clearly 10.25); and the auto-generated worktree name appears as both vigilant-fiestel and vigilant-fieste1 (l/1 glyph ambiguity) across the book's screenshots — the lesson standardizes on vigilant-fiestel. Book figures are screenshots (not reproduced; the 3 lesson diagrams are original SVGs).Lowneeds reviewOpen
2026-06-1510Chapter 10 ("Using Claude Code Desktop") built end-to-end (lesson, quiz, source ledger, training-output mirror, course.json → ready, estimatedMinutes 120). Facts verified against canonical Anthropic docs + blog/cookbook before authoring (parallel docs-drift + enrichment subagents). Book is the fastest-moving surface in the book (desktop/cloud/mobile UI); 9 drift items propagated across all four artifacts (ledger Drift table, dated 2026-06-15): "background agents" → cloud/background sessions; single local/cloud toggle → Local/Remote/SSH environment picker + multi-tab desktop; worktrees branch from origin/HEAD by default (worktree.baseRef:"head" to opt into local HEAD); worktree cleanup is conditional not automatic; CLI .claude/worktrees/<name> + worktree-<name> branch vs desktop auto-managed path (book shows ~/.claude-worktrees/...) — soft-worded; parallel-agents landscape is broader than the book's framing (subagents / agent teams [experimental, env-gated] / Agent View / dynamic workflows / /batch / multiple terminals); no magic "merge all branches" command (standard Git in a worktree, human-gated); mobile = two paths (Claude Code on the web [cloud] vs Remote Control [mobile→local session]); default cloud session has no custom MCP/hooks/output styles (from book, kept). Behavior authority = official docs; blogs (desktop-redesign / agent-view / claude-code-on-the-web) = announcement/color; multi-agent-research + Building-Effective-Agents + cookbook orchestrator-workers = concept/background ("as reported" token figures, NOT behavior). Dev server restarted (stopped PID 34892, fresh npm run dev on :4321) so the new ready route registers. Route renders at /chapters/10-chapter-10 (HTTP 200; 3 SVGs/3 figcaptions, 0 escaped &lt;svg, 6 quiz-question + passingScore, no AstroError; ch10 linked in sidebar). Quiz verified interactively via Playwright MCP (real browser): 6/6, inline feedback, no page reload (reload marker survived, URL unchanged), all 3 diagrams render; only console message is the expected favicon 404.Lowneeds reviewOpen
2026-06-1510Practical exercise uses a framework-free sandbox (~/cct-ch10-lab/) driven only by git + the Claude CLI — no desktop app, no cloud account, no npm/Next.js — reproducing the chapter's core mechanics locally: Part 1 one worktree + isolation; Part 2 a second parallel worktree (independent file); Part 3 integrate on a temporary project/hookhub-merge branch, force+resolve a CSS conflict, "test" gate, then merge to project/hookhub; Part 4 clean up worktrees. Uses raw git worktree (not claude --worktree) for determinism, noting the Claude shortcut. Verify claude --worktree / worktree defaults at code.claude.com/docs/en/worktrees before delivery (fast-moving surface).Lowneeds reviewOpen
2026-06-1610Re-audit — three over-broad Chapter 10 claims corrected and propagated across lesson + quiz + ledger + training-output (this supersedes the cloud-config / merge / base-ref wording in the 2026-06-15 build rows above; verified by re-fetching code.claude.com/docs/en/{desktop,worktrees,claude-code-on-the-web,github-actions,remote-control}). (1) Cloud config — the book's "a default cloud session runs without your MCP/hooks/output styles" is too broad. Per Claude Code on the web docs, a cloud session is a fresh clone, so repo-committed config IS available (CLAUDE.md, .claude/settings.json hooks, .mcp.json, `.claude/skillsagentscommands, plugins declared in .claude/settings.json); only user-local config doesn't carry over (~/.claude/…, plugins enabled only in user settings, MCP added via claude mcp add). Output styles are NOT doc-covered → no hard claim. (2) Base-ref vs cloud — worktree.baseRef (default origin/HEAD) governs local worktrees only; cloud checkout is a separate fresh-clone mechanism — the lesson no longer ties the cloud agent's wrong-branch to worktree.baseRef`. (3) Merge "human-gated" — scoped to the delegated local-merge workflow taught here; Desktop PR monitoring documents Auto-fix and Auto-merge (auto-merge requires the GitHub repo setting), so not every merge is manual. Ledger Drift rows #3/#7/#9 rewritten (row #9 now CORRECTION — book overbroad; NOT confirmed, not "kept from book"). Grep clean: lesson + quiz = 0 stale assertions; ledger + training-output retain the old wording only in documenting-the-correction context. Quiz JSON re-validated (6 q; answers b,a,c,b,c,b unchanged). Page re-rendered HTTP 200 (3 SVGs, no AstroError) + Playwright re-check 6/6, no reload. Output-styles-in-cloud remains unverified in docs — re-check on a later pass.Lowneeds reviewOpen
2026-06-1611Source PDF 11-chapter-11.pdf is image-only — 20 pages, no text layer (image-only check returned 0 chars). Rendered all 20 pages to PNG at 150 DPI with PyMuPDF into work/11-chapter-11-pages/ and transcribed visually (one subagent) into extracted-chapters/11-chapter-11.md. Mixed-fidelity: headings/code/commands/paths/tool-names verbatim; explanatory prose summarized. No .txt mirror. Page markers are PDF-page indices; page 20 = Packt back-matter promo (not chapter content). needs review: the page-1 "topics covered" bullet list is truncated by the page break — only two bullets render ("Agent taxonomy in production systems", "What makes an agent deep") before page 1 cuts off; the chapter's section headings (planning tool, subagents, filesystem, system prompt) confirm the rest of the topic list continued onto an uncaptured portion. Book figures (taxonomy/flowchart/architecture diagrams + terminal screenshots) not reproduced (the 3 lesson diagrams are original SVGs).Lowneeds reviewOpen
2026-06-1611Chapter 11 ("Understanding Deep Agents" — the final chapter) built end-to-end (lesson, quiz, source ledger, training-output mirror, course.json → ready, estimatedMinutes 115). All 11 chapters now ready — course complete (11/11). Facts verified against canonical Anthropic docs + LangChain DeepAgents source + Anthropic engineering/cookbook before authoring (parallel docs-drift + enrichment subagents). The chapter is conceptual (the four-pillar "deep agent" architecture). Drift propagated across all four artifacts (ledger Drift table, dated 2026-06-16): (1) "deep agent" is a community/LangChain term, NOT an Anthropic/Claude Code label (Anthropic says "long-horizon execution"; zero docs hits for "deep agent"); (2) the planning tool the book calls TodoWrite/TodoRead is the legacy surface — current Claude Code uses the **Task* family (TaskCreate/TaskList/TaskGet/TaskUpdate; TodoWrite disabled by default as of v2.1.142; /tasks to view), and the in-session to-do list is distinct from read-only plan mode; (3) "filesystem as a context engine" is an engineering principle**, not a documented Claude Code feature name (CC ships the file tools Read/Write/Edit/Glob/Grep/NotebookEdit + memory CLAUDE.md/auto-memory; the framing is from Anthropic's Effective context engineering post + LangChain's filesystem post); (4) subagent delegation is the Agent tool (formerly Task), isolated context + returns a summary (carried from Ch7). Source boundary: Claude Code behavior = official docs; LangChain DeepAgents (blog/docs/repo) = authoritative for the FRAMEWORK + the "deep agent" term, NOT Claude Code behavior; Anthropic engineering (Building Effective Agents / Effective context engineering / multi-agent research) + cookbook = concept/background (≈4×/≈15×/≈90.2% figures "as reported"); ReAct paper = academic foundation. Dev server restarted (stopped PID 70640, fresh npm run dev on :4321) so the new ready route registers. Route renders at /chapters/11-chapter-11 (HTTP 200; 3 SVGs/3 figcaptions, 0 escaped &lt;svg, 6 quiz-question + passingScore, no AstroError; homepage "11 of 11 chapters ready"; Ch10→Ch11 pager). Quiz verified interactively via Playwright MCP (real browser): 6/6, inline feedback, no page reload (reload marker survived, URL unchanged), all 3 diagrams render; only console message is the expected favicon 404. Grep-clean: lesson + quiz carry the corrected framing for every drift-sensitive term (TodoWrite always paired with "legacy"; "deep agent" framed as community/not-Anthropic; "context engine" framed as principle/not-feature).Lowneeds reviewOpen
2026-06-16CapstoneCapstone built — course now 12/12 complete (11 chapters + Capstone). Original pedagogical synthesis (no book chapter / no PDF / no extracted-chapters/ file). Framework-free, step-by-step devlog CLI build threading all 11 chapters (Stage 0 setup+CLAUDE.md gotcha → 1 plan mode → 2 build → 3 skill+output-style → 4 subagent review → 5 parallel worktrees+merge → 6 four-pillar reflection + MCP/Action notes), plus a cumulative final exam (content/chapters/12-capstone.quiz.json, 12 Q, passing 9/12, proportional across all chapters) that closes the deferred "final assessment covers all chapters proportionally" item. Built via the brainstorming flow (design spec at work/capstone-design.md). Four artifacts authored (lesson, exam, source ledger, training-output mirror). course.json: new Part 4 — Capstone, unit 12-capstone (kind capstone, ready, 120 min). Dev server restarted (PID 48364 → fresh on :4321); /chapters/12-capstone renders HTTP 200 (1 SVG, "Final exam" h2, "Passing score: 9", no AstroError); homepage "11 of 11 chapters ready" (capstone excluded); Ch11→Capstone pager. Verified interactively via Playwright (12/12, Passed, no reload).Lowneeds reviewOpen
2026-06-16Capstone (app)Small contained app edits to support the capstone as a non-chapter unit (no new components/routes): added a kind: "capstone" flag to the capstone entry in course.json; a unitLabel/selfLabel helper in app/src/pages/chapters/[slug].astro (labels it "Capstone" not "Chapter 12"; the quiz h2 conditionally reads "Final exam"); app/src/pages/index.astro excludes kind: capstone from the "N of N chapters ready" counter and labels the card "Capstone"; added kind? to the CourseChapter interface in app/src/content-loader.ts. Slightly more than the design spec's "one-line homepage tweak" hope, but contained to the two existing page files + the loader interface. Re-verify these still hold if the app template is refactored.Lowneeds reviewOpen
2026-06-16Deployment / appProduction build was broken — found & fixed during Azure prep (Phase 3). The project had only ever run npm run dev; npm run build failed because app/src/content-loader.ts resolved content/ relative to import.meta.url, which works in dev (app/src) but not in astro build (the bundled module lands in app/dist/chunks/, so it looked for app/content/course.json → ENOENT). Fixed: the loader now resolves the content root robustly (env override CONTENT_ROOT → cwd-based → both module-relative depths, picking the path that actually contains course.json). Build now succeeds → app/dist/ (14 pages, ~2.2 MB, static). Re-verify npm run build after any loader/config refactor.Mediumneeds reviewOpen
2026-06-16DeploymentAzure deployment prepared (target not yet chosen). App is a pure static site (Astro SSG, no server/secrets, content baked in at build) → Azure Static Web Apps recommended; container path prepared as the portable fallback. Artifacts added: app/public/staticwebapp.config.json (→ dist/ root, verified), Dockerfile (repo-root build context) + deployment/nginx.conf + .dockerignore, deployment/azure-static-web-apps.yml (SWA CI workflow template); deployment/azure-readiness.md rewritten into a full deployment guide with per-target ready steps. Pending from the user: the chosen target + Azure resource (+ for SWA, the deployment-token secret; for container, the ACR/registry). The actual deploy is outward-facing — done on instruction + confirmation.Lowneeds reviewOpen
2026-06-16CapstoneThe capstone is intentionally lab-shaped: one closing analogy ("the solo flight") + one SVG (Figure 12.A), following the practical-exercise pattern rather than the per-numbered-section-analogy lesson pattern — recorded in the source ledger so a reviewer doesn't flag it as a convention miss. MCP (Ch4) and the GitHub Action (Ch5) are touched only conceptually in the hands-on build (account/stack-heavy); the exam carries their proportional assessment. Re-verify the fast-moving surfaces (MCP/Action/output-styles/Task* naming) on later audits.Lowneeds reviewOpen
2026-06-1611Practical exercise is framework-free (~/cct-ch11-lab/) — Claude Code + git + a shell only, no npm/Node, no LangChain install, no API keys — and, since the chapter is conceptual, it has learners observe the four pillars run rather than build a deep agent: Part 1 a multi-step task → the Task* to-do list; Part 2 a subagent returning a summary from an isolated context (with /context before/after); Part 3 write state to NOTES.md + retrieve with grep/glob; Part 4 a CLAUDE.md heuristic reshaping behavior. Optional read-only stretch: open the LangChain DeepAgents base_prompt.md to compare. Verify the Task* tool names + the LangChain deepagents feature list against current docs/repo before delivery (both move fast).Lowneeds reviewOpen

Source ledgers

Chapter 1: Context Engineering

Source Ledger — Chapter 1: Context Engineering

Primary source (the book)

  • Source PDF: source-pdfs/01-chapter-01.pdf (21 pages)
  • Extracted source: extracted-chapters/01-chapter-01.md (cleaned) and extracted-chapters/01-chapter-01.txt (raw, form-feed page boundaries preserved)
  • Extraction tool: pdftotext -layout -enc UTF-8 (Poppler, shipped with Git for Windows)
  • OCR needed: No — extraction was clean text.

Enrichment sources

The lesson silently incorporates material from two external Anthropic publications. Per project convention, no inline > Source: or > Enrichment — ... labels appear in the learner-facing lesson — the labels caused visual confusion. This source ledger is the single source of provenance: every per-section mapping below tells you which paragraphs came from the book, which from Anthropic, and which were authored as pedagogical scaffolding for this training.

  • [E1] Anthropic engineering blog — "Effective Context Engineering for AI Agents" — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
  • [E2] Anthropic cookbook — "Context Engineering: Memory, Compaction, and Tool Clearing" — https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools

Pedagogical enrichment by the training author

The following additions are not from the book and not from Anthropic — they are pedagogical material written for this training. They are inventoried here so a reviewer can audit them separately. No inline labels are placed in the learner-facing lesson; only the > Analogy — ... callouts carry an in-lesson label.

  • Newcomer preface (## Before we start — agent, prompt, and context in plain language). Defines LLM, prompt, agent, harness, context, and context window in plain English for readers new to agent engineering.
  • Per-section analogies. Eleven > Analogy — ... callouts: one per numbered lesson section (§1–§6), one per Strategy sub-section (§4.1–§4.4), one at the top of §4 setting up the running "kitchen" analogy, and one closing whole-chapter analogy.
  • Whole-chapter analogy (## The whole chapter in one image — the long-shift chef). A sustained restaurant-kitchen analogy that re-frames the chapter's six sections for less-technical readers.
  • Four SVG diagrams authored for this training (not reproduced from the book's figures, which we do not have rights to):
  • Figure P.1 — "What's in the context window?" (preface).
  • Figure 1.A — "Context growth across turns" (§2).
  • Figure 1.B — "The four strategies at a glance" (§4 intro).
  • Figure 1.C — "The Goldilocks scale for system prompts" (§5).
  • Each figure has a figcaption that explicitly notes it is pedagogical and not from the book.
  • Practical exercise — "Drive context engineering in Claude Code." A ~30–45 minute hands-on walkthrough that takes the learner through Write / Select / Compress / Isolate plus a Goldilocks-zone sub-agent prompt rewrite, on a small sandbox project the learner creates locally. Includes seed file contents, step-by-step commands, expected outcomes, reflection prompts, and a success checklist. Sandbox project is created by the learner outside the training repo; nothing in the exercise modifies the training repo itself.

Quiz items and learning objectives remain grounded in the book chapter and the labeled Anthropic enrichment sources — none of the pedagogical analogies, diagrams, or exercise steps are themselves assessed.

Objective → Source Mapping

Learning ObjectiveSource Section (page)ConfidenceNotes
Explain why context engineering is a distinct concept from prompt engineering."From prompt engineering to context engineering" (p. 3)HighDirect claim: prompts are static, context is dynamic.
Describe the four Claude Code context strategies (Write/Select/Compress/Isolate)."Claude Code and its context engineering strategies" intro + Strategies 1–4 (pp. 5–13)HighStrategies named explicitly in the source.
Identify the three failure modes of unmanaged context: poisoning, confusion, clash."Why context matters for agents" (p. 4)HighEach failure mode is defined in the source.
Distinguish project memory, user memory, and dynamic memory imports."Strategy 1: Writing context and persistent memory" (pp. 6–8)HighThree tiers and @ import syntax shown in source.
Evaluate a system prompt against the Goldilocks zone."System prompts and why they matter" → "Goldilocks zone" + worked examples (pp. 14–20)HighSource provides specific/vague/middle examples used in quiz Q5.
(enrichment) Explain context engineering with the attention-budget and context-rot framing.[E1] §"Why context engineering is important"HighAdds Anthropic's named terms on top of the book's "degradation" framing.
(enrichment) Map slash commands to Anthropic API primitives and pick the right one for a workload.[E2] §"The Problem" + composition-strategy tableHighSource of §6 in the lesson and of quiz Q6.

Lesson Section → Source Mapping

Lesson sectionSource locationConfidence
Agent harness definitionpp. 2–3High
Sources of context (developer / user / prior interactions)p. 3High
Context window growth and degradationpp. 3–4 (Figures 1.1–1.3)High
Poisoning / confusion / clashp. 4High
Three-tier memory + @ importspp. 6–8High
Idempotent add_context helper using grep -qxFpp. 8–10High — quoted directly from source
Hook example (UserPromptSubmit)p. 10High
Folder discovery + /memory editor + ask-Claude-to-remember + tool-specific reminderspp. 10–11 (book) + current Anthropic memory docsHigh — corrected on post-launch audit. The book's /memory add ... CLI syntax was replaced. Current Claude Code uses /memory as an interactive editor and exposes two documented ways to push a fact in: ask Claude in natural language to "remember X" (Claude saves to auto-memory under ~/.claude/projects/<project>/memory/) or ask Claude to "add this to CLAUDE.md" (Claude edits the file). Source: https://code.claude.com/docs/en/memory §"View and edit with /memory" and §"Auto memory"; https://code.claude.com/docs/en/commands /memory description.
/clear vs /compactpp. 11–12High
Sub-agents and the YAML caveatpp. 12–13High — caveat about illustrative Task(...) syntax is quoted from source
Goldilocks zone (too specific / too vague / middle ground)pp. 14–20High — bakery assistant examples used verbatim in quiz Q5

Enrichment section → source mapping

Lesson locationEnrichment contentExternal source
§2 (context growth)"Attention budget", "context rot", "smallest set of high-signal tokens" quote[E1] §"Why context engineering is important"
§3 (failure modes)All three failures + recall degradation framed under "context rot"; context windows of all sizes affected[E1] §"Why context engineering is important"
§4.1 (Write)Structured note-taking; Pokémon multi-step tally example; file system as implicit memory[E1] §"Context engineering for long-horizon tasks"
§4.2 (Select) — retrievalJust-in-time vs pre-inference vs hybrid retrieval; progressive disclosure[E1] §"Context retrieval and agentic search"
§4.2 (Select) — tool designSelf-contained / robust / clear tools; descriptive parameters; minimize overlap[E1] tool-design discussion
§4.3 (Compress)Platform-primitive table (compaction / clearing / memory); "high-level survives, obscure lost" finding; clearing as cheapest compaction[E2] §"How the Three APIs Map to the Problem" + experimental results
§4.4 (Isolate)Sub-agents framed alongside compaction and structured note-taking[E1] §"Context engineering for long-horizon tasks"
§5 (Goldilocks)"Anatomy of effective context" — XML/markdown section organization; "examples are pictures worth a thousand words"; "do the simplest thing that works"[E1] §"The anatomy of effective context" + §"Conclusion"
§6 (NEW — all enrichment)Diagnostic mapping workload→primitive; composition order (clearing→compaction→memory); exclude_tools=["memory"] guidance[E2] §"All-Three Primitives Combined" + diagnostic output

Quiz Items → Source Mapping

Quiz IDItemSource locationConfidence
q1Prompt vs context engineeringp. 3High
q2Four strategiesp. 5High
q3Idempotent context-switcher hookpp. 8–10High
q4/clear vs /compactpp. 11–12High
q5Goldilocks-zone bakery promptpp. 14–20High
q6Workload → platform primitive (synthesis)[E2] diagnostic mapping table + composition strategyHigh — answer grounded in lesson §6 enrichment

Figures Referenced In Source (not reproduced in training)

FigureCaption (paraphrased)Status
1.1LLM Context WindowReferenced in lesson text; image not reproduced — described in prose.
1.2LLM Tool Calling LoopReferenced; described in prose.
1.3Context Growth Across Multiple TurnsReferenced; described in prose.
1.4Categories of context engineeringReferenced; replaced by the four-strategy table.
1.5Goldilocks Zone for System PromptsReferenced; described in prose with link to Anthropic source.

Unsupported Or Unclear Items

ItemIssueAction
Exact pages for each strategy headingForm-feed extraction puts each chapter PDF "page" at roughly one screen — book page numbers may differ from PDF page numbers.Confidence ranges based on PDF page positions. Cross-check with the printed book if exact pagination is required.
Task(...) sub-agent syntaxSource explicitly labels it illustrative; real YAML format comes later in the book.Lesson preserves the caveat verbatim.

Optional Enrichment

None added in this unit. All lesson content is grounded in the chapter source.

Chapter 2: The Gist of Claude Code

Source Ledger — Chapter 2: The Gist of Claude Code

Primary source (the book)

  • Source PDF: source-pdfs/02-chapter-02.pdf
  • Extracted source: extracted-chapters/02-chapter-02.txt (raw, form-feed page boundaries preserved)
  • Extraction tool: pdftotext -layout -enc UTF-8 (Poppler, shipped with Git for Windows)
  • OCR needed: No — extraction was clean text.

Enrichment sources

The lesson silently incorporates material from three official Anthropic documentation pages. Per project convention, no inline > Source: or > Enrichment — ... labels appear in the learner-facing lesson — the labels caused visual confusion in Chapter 1 and were dropped. This source ledger is the single source of provenance: every per-section mapping below tells you which paragraphs came from the book, which from Anthropic docs, and which were authored as pedagogical scaffolding for this training.

  • [E1] Anthropic docs — How Claude remembers your project — https://code.claude.com/docs/en/memory
  • [E2] Anthropic docs — Connect Claude Code to tools via MCP — https://code.claude.com/docs/en/mcp
  • [E3] Anthropic docs — Configure permissions — https://code.claude.com/docs/en/permissions
  • [E4] Anthropic docs — Choose a permission mode — https://code.claude.com/docs/en/permission-modes (added on the post-launch audit pass — needed to accurately describe plan-mode entry/exit and the approval flow)
  • [E5] Anthropic docs — Settings — https://code.claude.com/docs/en/settings (added on the post-launch audit pass — used in the §2 memory-vs-settings callout to cite the actual settings precedence chain)
  • [E6] Anthropic docs — Commands — https://code.claude.com/docs/en/commands (added on the post-launch audit pass — used to confirm canonical slash-command names like /model singular and to confirm /exit-plan-mode is not a documented command)

The user explicitly asked for enrichment "only where needed — do not overcomplicate." Three sources is intentional: it's enough to cover the chapter's three load-bearing topics (memory, MCP, permissions) with depth the book doesn't have, without adding noise.

Pedagogical enrichment by the training author

The following additions are not from the book and not from Anthropic — they are pedagogical material written for this training. They are inventoried here so a reviewer can audit them separately. No inline labels are placed in the learner-facing lesson; only the > Analogy — ... callouts carry an in-lesson label.

  • Newcomer preface (## Before we start — Claude Code, MCP, plan mode, and spec-driven design in plain language). Defines Claude Code, CLAUDE.md, MCP, plan mode, and spec-driven design in plain English for readers new to agent engineering.
  • Per-section analogies. Seven > Analogy — ... callouts: one per numbered lesson section (§1 hotel check-in, §2 house rules on the fridge, §3 hotel keycard, §4 USB devices, §5 binder tabs, §6 blueprint), plus one closing whole-chapter analogy.
  • Whole-chapter analogy (## The whole chapter in one image — onboarding a new contractor). A sustained "new contractor on site" analogy that re-frames the chapter's six sections for less-technical readers.
  • Three SVG diagrams authored for this training (not reproduced from the book's figures, which we do not have rights to):
  • Figure P.1 — "The four things Chapter 2 wires up around Claude Code" (preface): memory, MCP, plan mode, permission gate.
  • Figure 2.A — "CLAUDE.md scope ladder" (§2): managed → user → project → local with load order arrow.
  • Figure 2.B — "Every tool call passes through the gate" (§3): the deny → ask → allow evaluation flow.
  • Each figure has a figcaption that explicitly notes it is pedagogical and not from the book.
  • Practical exercise — "Drive the Chapter 2 setup in Claude Code." A ~30–45 minute hands-on walkthrough that takes the learner through /init, hand-editing CLAUDE.md with conventions, exercising all three permission-prompt options, plan-mode-driven spec writing, implementation against the spec via @ reference, optional MCP install with claude mcp add ... -s user, and a continuity check across /compact / /clear / /exit. Built on a Linkroll sandbox project (a Python stdlib CLI) the learner creates locally. Deliberately swapped from the book's Next.js / HookHub stack to keep the prerequisite footprint small (Python is on most machines; Node is gated to an optional step).
  • Sandbox swap rationale. The book's HookHub project requires Node, npx, npm permissions, and a Next.js scaffolding pass before the learner reaches the Claude Code mechanics. The Chapter 2 exercise keeps the focus on the Claude Code mechanics by using a Python stdlib CLI instead — same lessons, fewer install steps. Learners who want the full HookHub experience can follow the book's setup directly; nothing in the training contradicts it.

Quiz items and learning objectives remain grounded in the book chapter and the labeled Anthropic enrichment sources — none of the pedagogical analogies, diagrams, or exercise steps are themselves assessed.

Objective → Source Mapping

Learning ObjectiveSource SectionConfidenceNotes
Project directory as Claude's unit of context — launch location matters.Book §"Initializing Claude code" (pp. ~5–6 of extracted text) + [E1] §"How CLAUDE.md files load"HighBook introduces the idea via /init; [E1] formalizes the up-walk discovery rule.
Explain /init and what it generates.Book §"Initializing Claude code" (pp. ~5–7)HighBook lists the exact contents Claude infers: project goal, business problem, run command, frameworks, folder structure.
Name the four CLAUDE.md scope levels and load order.[E1] §"Choose where to put CLAUDE.md files"HighBook introduces project-level only; the four-level ladder (managed/user/project/local) is enrichment.
Use the permission prompt deliberately — Yes / Yes-session / No semantics.Book §"Contents of the CLAUDE.md file" → permission prompt block (p. ~7)HighThree-option prompt is quoted verbatim from the source.
claude mcp add with --scope choice.Book §"Connecting Playwright MCP to Claude Code" (pp. ~9–10) + [E2] §"MCP installation scopes"HighBook introduces -s user; [E2] adds the three-scope table and the storage locations.
Plan mode + spec-driven design workflow.Book §"Using spec-driven design" + §"Implementing the main page using the SPEC" (pp. ~15–20)HighThe Shift+Tab toggle, the Opus-for-planning / Sonnet-for-implementation switch, and the @spec reference at implementation time are all from the book.
(enrichment) deny → ask → allow evaluation order.[E3] §"Manage permissions"HighSource of quiz Q6.
(enrichment) Project-root CLAUDE.md survives /compact.[E1] §"Instructions seem lost after /compact"HighMentioned in §6 as the reason CLAUDE.md rules persist through context resets.

Lesson Section → Source Mapping

Lesson sectionSource locationConfidence
§1 — launching from the right directoryBook "Initializing Claude code" framing + [E1] up-walk discovery ruleHigh — corrected on review. The walk goes up only; siblings are never visited; launching from a subdirectory still finds the project-root CLAUDE.md. The real risks (launching too high, missing project, inheriting unintended parent rules) are sourced from [E1] §"How CLAUDE.md files load". /memory is documented as the inspect command.
§2 — /init and what it produces (contents listed)Book §"Contents of the CLAUDE.md file" (p. ~7) — quoted directlyHigh
§2 — when to add to CLAUDE.md (the four triggers)[E1] §"When to add to CLAUDE.md"High
§2 — under-200-lines guidance[E1] §"Write effective instructions → Size"High
§2 — four-scope ladder (accumulates, doesn't override)[E1] §"Choose where to put CLAUDE.md files" — table reproduced (with project marked as /init target). Lesson explicitly notes that CLAUDE.md files accumulate (concatenated into context together), and that managed-policy CLAUDE.md "cannot be excluded by individual settings" per [E1] §"Manage CLAUDE.md for large teams".High
§2 — memory ≠ settings callout (instructions accumulate; permissions enforce)Memory accumulation behavior from [E1]; settings precedence (managed > command-line > local > project > user) from Anthropic docs §Settings; permission deny → ask → allow from [E3]High — corrected on review. Previous lesson incorrectly implied a project CLAUDE.md could "override" a managed policy.
§3 — three-option permission promptBook p. ~7 — quoted verbatimHigh
§3 — practicing safe agentic coding rationaleBook p. ~8 — quoted nearly verbatimHigh
§3 — three rule types (allow/ask/deny) and evaluation order[E3] §"Manage permissions"High
§3 — rule syntax (Bash(npm run *), Read(.env), etc.)[E3] §"Permission rule syntax"High
§3 — permission modes (default / acceptEdits / plan / auto / dontAsk / bypassPermissions)[E3] §"Permission modes"High
§4 — what MCP is, in one line[E2] header — quotedHigh
§4 — MCP install command syntax[E2] §"Option 3: Add a local stdio server" — current syntax claude mcp add --scope user playwright -- npx @playwright/mcp@latest. The -- separator is required for stdio servers per [E2] ("the -- (double dash) separates Claude's own options … from the command and arguments that run the server"). Book p. ~10 shows the older -s user form; lesson explicitly notes the short form still works.High
§4 — three MCP scopes (local / project / user) and storage locations[E2] §"MCP installation scopes" — table reproducedHigh
§4 — /mcp verifies connectionsBook p. ~10 + [E2] §"Managing your servers"High
§4 — "verify you trust each server before connecting"[E2] front-matter warning — quotedHigh
§5 — memory/frontend/CLAUDE.md not auto-loadedBook §"Creating a frontend memory context" (pp. ~13–14) — note from the source quotedHigh
§5 — @ import syntax (4-hop max, paths relative to importing file)[E1] §"Import additional files"High
§5 — .claude/rules/ with paths: glob frontmatter[E1] §"Organize rules with .claude/rules/" + §"Path-specific rules"High
§5 — final book layout memory/{frontend,spec}/CLAUDE.mdBook p. ~20 — reproduced verbatimHigh
§6 — plan mode (entry Shift+Tab or /plan, read-only tools only)Book §"Using spec-driven design" (p. ~16) + [E4] §"Analyze before you edit with plan mode" — verbatim entry instructionsHigh
§6 — leaving plan mode (Shift+Tab again, or approve plan → exits to chosen permission mode)[E4] verbatim: "Press Shift+Tab again to leave plan mode without approving a plan" / "Approving a plan exits plan mode and switches the session to the permission mode each approve option describes." [E6] confirms /exit-plan-mode is not in the canonical command list.High — corrected on review. Previous lesson referenced /exit-plan-mode.
§6 — Opus for planning, Sonnet for implementation, /model to switchBook p. ~17 — Opus/Sonnet routing. Command name corrected to /model (singular) per [E6] canonical commands table.High — corrected on review. Previous lesson used /models (plural).
§6 — spec at memory/spec/CLAUDE.md, referenced with @ at implementation timeBook pp. ~18–20 — verbatimHigh
§6 — /exit + restart pattern for a hard resetBook pp. ~19–20 — verbatimHigh
§6 — project-root CLAUDE.md survives /compact[E1] §"Instructions seem lost after /compact"High

Quiz Items → Source Mapping

Quiz IDItemSourceConfidence
q1/init is the first command; produces project goal, tech stack, build/run commands, structureBook p. ~7High
q2Three-option permission prompt is the practical embodiment of safe agentic codingBook pp. ~7–8High
q3--scope user flag scopes MCP install to every project on this machine, just you (short form -s user also works)[E2] scopes table + [E2] §"Option 3: Add a local stdio server" for the -- separator. Prompt updated on post-launch audit to use current official syntax.High
q4Files in memory/ are not auto-loaded — must be referenced explicitlyBook p. ~14 — quoted noteHigh
q5Spec-driven workflow: plan mode + Opus → spec file → fresh session + @ reference + SonnetBook pp. ~16–20High
q6deny → ask → allow evaluation; user-level deny beats project-level allow[E3] §"Manage permissions" + §"Settings precedence" — synthesisHigh

Figures Referenced In Source (not reproduced in training)

FigureCaption (paraphrased)Status
2.1project/hookhub branchReferenced in source; not reproduced.
2.2Default Next.js application running on localhost:3000Referenced; not reproduced.
2.3Claude Code opened via Cursor IntegrationReferenced; not reproduced.
2.4"Booping" in Cursor IntegrationReferenced; not reproduced.
2.5Generated CLAUDE.md file with project overview and commandsReferenced; described in prose (§2 lists the contents).
2.6Running Claude Code CLI in the terminalReferenced; not reproduced.
2.7Verifying MCP Server Connections in Claude CodeReferenced; described in prose (§4 mentions /mcp).
2.8Playwright MCP Permission Prompt to Open a BrowserReferenced; described in prose (§3 covers prompt).
2.9Browsing Cursor Directory for Next.js RulesReferenced; not reproduced.
2.10Generic Claude Response Without Loaded Project ContextReferenced; described in prose (§5 covers the "Claude answered generically" demo).
2.11Claude's Proposed Plan for HookHub MVP SpecificationReferenced; described in prose (§6 lists the plan's contents).
2.12HookHub Product Specification in CLAUDE.mdReferenced; not reproduced.
2.13Claude Implementation Summary After Code GenerationReferenced; not reproduced.
2.14Basic Next.js applicationReferenced; not reproduced.

Unsupported Or Unclear Items

ItemIssueAction
Exact pages for book section headingsThe PDF extraction does not preserve printed book page numbers — references in this ledger are PDF page positions in the extracted text.Confidence ranges based on extracted-text page positions. Cross-check with the printed book if exact pagination is required.
/security-review sub-agent mention in sourceBook mentions a /security-review sub-agent appearing after restart; the source defers depth to Chapter 3.Lesson §3 mentions modes briefly and defers permission-mode depth to Chapter 3 to match the book's own deferral.
Cursor Integration screenshotsBook uses Cursor as the IDE wrapper. Training is IDE-agnostic — terminal-only is sufficient for the lesson and the exercise.Lesson never claims Cursor is required.

Optional Enrichment

None added beyond the three labeled enrichment sources. The user's explicit guidance was to keep enrichment minimal and "only where needed."

Chapter 3: A Tour of Essential Commands

Source Ledger — Chapter 3: A Tour of Essential Commands

Primary source (the book)

  • Source PDF: source-pdfs/03-chapter-03.pdf (45 form-feed pages in the extraction)
  • Extracted source: extracted-chapters/03-chapter-03.md (cleaned, with <!-- page N --> markers) and extracted-chapters/03-chapter-03.txt (raw, form-feed page boundaries preserved)
  • Extraction tool: pdftotext -layout -enc UTF-8 (Poppler, shipped with Git for Windows)
  • OCR needed: No — extraction was clean text.

Enrichment sources

The lesson silently incorporates material from the official Anthropic documentation, the Anthropic engineering blog, the Anthropic news feed, the Anthropic cookbook, the Claude pricing page, and one outside post that the book itself cites (LangChain on CAIR). Per project convention, no inline > Source: or > Enrichment — ... labels appear in the learner-facing lesson — the labels caused visual confusion in Chapter 1 and were dropped. This source ledger is the single source of provenance: every per-section mapping below tells you which paragraphs came from the book, which from labelled enrichment, and which were authored as pedagogical scaffolding for this training.

  • [E1] Anthropic docs — Settings — https://code.claude.com/docs/en/settings
  • [E2] Anthropic docs — Commands — https://code.claude.com/docs/en/commands
  • [E3] Anthropic docs — Hooks — https://code.claude.com/docs/en/hooks
  • [E4] Anthropic docs — How Claude remembers your project — https://code.claude.com/docs/en/memory
  • [E5] Anthropic docs — Checkpointing — https://code.claude.com/docs/en/checkpointing
  • [E6] Anthropic docs — Extend Claude with skills — https://code.claude.com/docs/en/skills
  • [E7] Anthropic docs — VS Code & Cursor extension — https://code.claude.com/docs/en/vs-code
  • [E8] Anthropic engineering — Equipping agents for the real world with Agent Skills — https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
  • [E9] Anthropic engineering — Best practices for Claude Code — https://www.anthropic.com/engineering/claude-code-best-practices
  • [E10] Anthropic news — How Anthropic teams use Claude Code — https://www.anthropic.com/news/how-anthropic-teams-use-claude-code
  • [E11] Anthropic cookbook — Introduction to Claude Skills — https://platform.claude.com/cookbook/skills-notebooks-01-skills-introduction
  • [E12] Anthropic cookbook — Building custom Skills for Claude — https://platform.claude.com/cookbook/skills-notebooks-03-skills-custom-development
  • [E13] Claude pricing page — https://claude.com/pricing
  • [E14] LangChain — The Hidden Metric That Determines AI Product Success — https://blog.langchain.com/the-hidden-metric-that-determines-ai-product-success/

This count is larger than Chapters 1 and 2 because Chapter 3 is the book's "everything you'll touch daily" chapter — settings, commands, hooks, memory, checkpoints, and Skills — and every one of those surfaces has materially changed in Anthropic's docs since the book went to print. Enrichment is used to correct and update the book rather than to add unrelated material.

Pedagogical enrichment by the training author

The following additions are not from the book and not from Anthropic — they are pedagogical material written for this training. They are inventoried here so a reviewer can audit them separately. No inline labels are placed in the learner-facing lesson; only the > Analogy — ... callouts carry an in-lesson label.

  • Newcomer preface (## Before we start — billing, hooks, checkpoints, and Skills in plain language). Defines billing modes, hook, checkpoint, and Skill in plain English for readers new to agent engineering.
  • Per-section analogies. Seven > Analogy — ... callouts: one per numbered lesson section (§1 three ways to buy electricity for the workshop, §2 the control panel and the wall plates, §3 the safety interlocks on a workshop press, §4 the workshop's notebooks, §5 the press-the-button undo on a workbench, §6 the workshop's jigs), plus one closing whole-chapter analogy (the workshop tour).
  • Whole-chapter analogy (## The whole chapter in one image — the workshop tour). A sustained workshop analogy that re-frames the chapter's six sections — billing, control panel, interlocks, notebooks, camera, jigs — for less-technical readers.
  • Two SVG diagrams authored for this training (not reproduced from the book's figures, which we do not have rights to):
  • Figure P.1 — "The six surfaces this chapter wires up" (preface): billing & auth, slash commands, hooks, memory, rewind/checkpoints, Skills, arranged around the Claude Code core.
  • Figure 3.A — "CAIR — and where /rewind moves the needle" (§5): the Value / (Risk × Correction) formula with an arrow showing that /rewind lowers Correction and thereby raises CAIR.
  • Each figure has a figcaption that explicitly notes it is pedagogical and not from the book.
  • Practical exercise — "Drive every surface in this chapter." A ~30–45 minute hands-on walkthrough that takes the learner through a fresh ~/cct-ch3-exercise/ sandbox: settings hot-reload and a deny rule, three-tier memory (project / user / auto-memory), building a Stop hook and demonstrating exit-2-blocks-vs-exit-1-doesn't, /rewind for code-only restore and confirming it can't undo bash side effects, and authoring a .claude/skills/commit-summary/SKILL.md with allowed-tools and !-injection. Includes a success checklist, reflection prompts, and common pitfalls. Sandbox is created outside the training repo; nothing in the exercise modifies the training repo itself.

Quiz items and learning objectives remain grounded in the book chapter and the labelled enrichment sources — none of the pedagogical analogies, diagrams, or exercise steps are themselves assessed.

Objective → Source Mapping

Learning ObjectiveSource Section (page)ConfidenceNotes
Pick the right authentication path (API key / subscription / third-party cloud) and explain billing & monitoring for each.Book §"Pricing and plans for Claude Code" → "Option 1: Using an Anthropic API key" / "Option 2: Using a Claude subscription" / "Option 3: Using a third-party cloud provider" (pp. 2–9) + [E13]HighThree options enumerated in source. Tier prices quoted from p. 6; verify current at [E13].
Drive Claude Code with the everyday slash commands and place each setting in the right scope (managed / user / project / local).Book §"Controlling Claude Code with slash commands" (pp. 9–12) + [E1] §"Settings precedence" + [E2] commands inventoryHigh — book lists three tiers; [E1] adds the fourth (managed) tier plus precedence Managed → CLI → Local → Project → User, and the permission-merge exception.
Build a hook end to end: pick event, write handler, register, signal a block with exit code 2 — and explain why hooks are not a security boundary.Book §"Using hooks in Claude Code" → "Creating a notification hook" steps 1–14 (pp. 13–20) + [E3] event catalogue + [E3] exit-code semantics + [E9] hooks-as-deterministic-verification framingHigh — book lists 5 events; [E3] documents many more; book never mentions exit-2-blocks-vs-exit-1-doesn't, which is the single most-missed detail and is sourced from [E3].
Lay out a CLAUDE.md across five memory tiers (managed → user → project → rules → local) plus the auto-memory subsystem.Book §"Understanding memory in Claude Code" (pp. 20–26) + [E4] tier 4 (./.claude/rules/*.md) + [E4] auto-memory subsystemHigh — book mostly covers tiers 1–3 and 5; tier 4 (./.claude/rules/) is implied in source p. 23 but the path-glob frontmatter is from [E4]. Auto-memory (v2.1.59+) is not in the book at all.
Use /rewind (and Esc Esc) deliberately — pick between the five restore/summarize actions, explain what checkpoints capture and what they don't.Book §"Rewind feature in Claude Code" (pp. 32–37) + [E5]High — book lists three restore actions; [E5] documents five (the two summarize-here/summarize-up-to-here actions are post-book additions).
Author a custom slash command as a Skill — SKILL.md with frontmatter, allowed-tools scope, !-injection — and explain why the modern Skills shape replaces the older .claude/commands/ form.Book §"Custom slash commands in Claude Code (powered by Skills)" (pp. 37–43) + [E6] canonical example + [E8] progressive-disclosure metaphorHigh — book introduces the merger note (p. 1 sidebar and p. 20 sidebar) and the canonical commit example (pp. 40–42); [E6] is the canonical reference for the frontmatter fields and the !-injection mechanism.
(enrichment) Explain CAIR (Confidence in AI Results) and how rewind lowers Correction.Book p. 33 (cites the metric, calls it "Cost of AI Recovery") + [E14] (canonical post; correct expansion is "Confidence in AI Results")High — explicit name disagreement called out in the lesson and in §Unsupported below.

Lesson Section → Source Mapping

Lesson sectionSource locationConfidenceNotes
§1 — three options for billing/authBook pp. 2–9HighAPI-key risks (leakage, runaway agent fan-out) and the spending-limit mitigation are quoted from pp. 4–5; subscription tiers from p. 6; third-party cloud from p. 9.
§1 — /cost / /stats are now aliases for /usageBook p. 4 (/cost) and p. 7 (/usage) introduce these separately; [E2] documents them as aliasesHigh — corrected on review. Book treats /cost and /usage as two separate commands tied to auth mode; [E2] explicitly aliases them.
§1 — model picker mental model (Sonnet/Opus/Haiku)Book p. 7 (the three-model description with 200K context windows)High
§2 — slash-commands surface tableBook p. 9 (intro: "type / and Claude Code shows the list") + [E2] (full inventory)High — book lists ~8 commands; lesson lists 15 with aliases per [E2].
§2 — /vim and /pr-comments removed[E2] §"Removed commands"High — book doesn't cover this; included so learners don't follow stale tutorials.
§2 — /clear vs /compact day-to-day patternBook p. 10 — quoted directlyHigh
§2 — four-tier settings hierarchy (Managed / User / Project / Local)Book pp. 11–12 (three tiers: user / project / local) + [E1] (adds Managed as the fourth and highest tier, plus managed-settings.d/ directory)High — corrected on review. Book omits the Managed tier; [E1] documents it.
§2 — precedence Managed → CLI → Local → Project → User[E1] §"Settings precedence"High
§2 — permission rules merge across scopes, do not override[E1] §"Settings precedence" — the only documented exception to the override ruleHigh — this exception is not in the book at all. Single most consequential update for team configuration.
§2 — hot reload + model/outputStyle restart exception + five-backups[E1] §"Hot reload of settings" and §"Settings auto-backups"High — not in the book.
§2 — $schema autocomplete snippet[E1] §"Schema validation in your editor"High — not in the book.
§2 — IDE integration: one extension serves VS Code & CursorBook pp. 12–13 (Cursor demo only) + [E7] (anthropic.claude-code for both editors via Open VSX)High — corrected on review. Book uses Cursor exclusively; [E7] documents the one-extension-two-editors reality.
§2 — Cmd/Ctrl+Esc focus toggle, selection-as-context, @-mentions, diff view, ide MCP server with two tools[E7] §"Use Claude Code in your IDE"High — not in the book.
§2 — /ide to connect external terminal Claude Code to an open editor[E7]High
§3 — hooks introBook pp. 13–14 — quotedHigh
§3 — event catalogue table (PreToolUse / PostToolUse / UserPromptSubmit / Notification / Stop / Session* / Subagent* / PreCompact / PostCompact)Book p. 17 lists 5 events; [E3] documents many more (full catalogue at the canonical URL — exact count moves with releases, so the lesson uses "many more" wording rather than a hard number)High — corrected on review. Book is a strict subset.
§3 — "play a sound on Stop" hook walkthrough (5 build steps, JSON shape)Book pp. 14–19 (the 14-step IceBreaker walkthrough), condensed to 5 conceptual stepsHigh — JSON shape on p. 18 reproduced essentially verbatim; uv/pygame Python path mentioned but lesson notes afplay/aplay as the faster alternative (a "Pro Tip" the book itself gives on p. 20).
§3 — exit code 2 blocks, exit code 1 doesn't[E3] §"Exit codes" — quoted: "If your hook is meant to enforce a policy, use exit 2"High — corrected and added on review. The single most-missed detail; not in the book.
§3 — hooks are not a security boundary; use permissions for hard rules[E3] §"Hooks vs permissions" + [E9] hooks-as-deterministic-verification framingHigh — added on review. Book frames hooks as "blocking unsafe edits" (p. 13), which overstates their guarantee.
§3 — high-frequency hooks should be lightweightBook p. 20 ("Pro Tip" — quoted verbatim)High
§4 — memory introductionBook pp. 20–21 — quotedHigh
§4 — five-tier memory table (Managed / User / Project / Rules / Local)Book pp. 21–24 (lists levels 1, 2, 3, 4, 5) + [E4] (formalises tier 4 with paths: glob frontmatter)High
§4 — upward discovery + lazy loading of subtree memoryBook pp. 24–25 (IceBreaker directory tree, three-file load result) — quotedHigh
§4 — @-import 4-hop cap[E4] §"Import additional files"High — not in the book.
§4 — under-200-lines guidance[E4] §"Write effective instructions → Size" + book's general "keep memory files concise" guidance (p. 26)High — concrete 200-line number is from [E4].
§4 — auto-memory subsystem (v2.1.59+)[E4] §"Auto memory"High — added on review. Not in the book at all. Includes MEMORY.md index, 200-line/25KB first-load cap, topic files loaded on demand, CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 toggle.
§4 — three ways to add a memory entry (#, natural language, /memory directly)Book pp. 25, 30–31 (the # shortcut and /memory editor) + [E4] (the natural-language path and auto-memory)High
§4 — /init interactive multi-phase flow with CLAUDE_CODE_NEW_INIT=1[E4] §"Initialize memory" / book p. 27 (basic /init only)High — book covers basic /init; interactive multi-phase flow is from [E4].
§5 — checkpoint intro + Esc-twice triggerBook p. 32 — quotedHigh
§5 — Esc Esc only opens rewind when prompt is empty[E5] §"Triggering rewind"High — corrected on review. Book doesn't mention the empty-prompt precondition.
§5 — five restore/summarize actions (Restore code & conversation / Restore conversation / Restore code / Summarize from here / Summarize up to here)Book pp. 36 (lists three restore actions) + [E5] (documents five)High — corrected on review. Two summarize actions are post-book additions.
§5 — checkpoint retention 30 days + what they don't capture (bash side effects, manual edits, anything beyond 30 days)Book p. 37 (lists three limitations) + [E5] (formalises and quotes "local undo vs Git permanent history")High
§5 — CAIR formula with Value / (Risk × Correction) decomposition[E14] LangChain post — the canonical sourceHigh — book p. 33 cites the same blog post but expands the acronym as "Cost of AI Recovery"; canonical post uses "Confidence in AI Results". Lesson uses the canonical name and explicitly notes the disagreement.
§5 — rewind as a Correction-lowering mechanism that raises CAIR[E14] — direct applicationHigh — synthesis, not in the book.
§6 — Skills merger (custom commands unified under Skills)Book p. 1 sidebar + p. 20 sidebar + [E6] header — quoted from [E6]: "Custom commands have been merged into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way."High
§6 — progressive disclosure (3 levels: name+description → SKILL.md → linked files)[E8] §"Progressive disclosure" — the "table-of-contents manual" metaphor quotedHigh — not in the book.
§6 — minimal SKILL.md anatomyBook pp. 38–39 (the original short prompt + frontmatter intro) + [E6] (frontmatter field reference)High
§6 — frontmatter field table (name/description/when_to_use/argument-hint/allowed-tools/disallowed-tools/disable-model-invocation/user-invocable/model) + 1,536-char metadata cap[E6] frontmatter referenceHigh — not in the book.
§6 — $ARGUMENTS placeholderBook pp. 39–40 — quotedHigh
§6 — !-injection of shell commands at expansion time[E6] §"Dynamic context with !" + the canonical commit exampleHigh — book reproduces this exact example on pp. 40–42 but doesn't name the mechanism; [E6] does.
§6 — canonical docs commit-message skill (verbatim)Book pp. 40–41 (quotes the example directly from Claude Code docs) + [E6] (source of truth)High
§6 — allowed-tools is a grant (pre-approves listed tools without per-use prompts; does not restrict — hard blocks require disallowed-tools or permissions.deny); !-injection ≈ RAG in a slash commandBook p. 42 (explicit "this is RAG" connection) + [E6] §"allowed-tools" — quoted verbatim: "grants permission for the listed tools while the skill is active. It does not restrict which tools are available."High — corrected on review. Earlier ledger wording said allowed-tools "enforces least privilege"; the official Skills docs are explicit that the field grants pre-approval rather than restricting access. The lesson, quiz Q6, jig analogy, and practical-exercise step 5.5 were all reworked to match.

Enrichment section → source mapping

Lesson locationEnrichment contentExternal source
§1 (auth)/cost+/stats as aliases for /usage; full alias list[E2]
§1 (auth)Pricing verification disclaimer + link[E13]
§2 (slash commands)Full 15-row slash command inventory; /vim and /pr-comments removal[E2]
§2 (settings)Managed tier (fourth and highest); precedence chain; permission-rule merge exception; hot reload + restart exceptions; five-backup auto-rotation; $schema autocomplete[E1]
§2 (IDE)One extension for VS Code + Cursor; Cmd/Ctrl+Esc focus toggle; selection-as-context; @-mentions; diff view; built-in ide MCP server with two tools; /ide reconnect[E7]
§3 (hooks)Expanded event catalogue (vs the book's 5 — exact count varies by release, so the lesson uses "many more" wording); exit-code 2 blocks vs 1 doesn't; hooks-are-not-a-security-boundary; "use permissions for hard policy, not hooks"[E3] + [E9]
§4 (memory)@-import 4-hop cap; under-200-lines guidance; full auto-memory subsystem (MEMORY.md index, 200-line/25KB load cap, on-demand topic files, env-var disable); interactive /init with CLAUDE_CODE_NEW_INIT=1; project-rules paths: frontmatter[E4]
§5 (rewind)Esc-Esc empty-prompt precondition; five restore/summarize actions; "local undo vs Git permanent history" framing; 30-day retention; explicit list of what checkpoints don't capture[E5]
§5 (CAIR)Canonical "Confidence in AI Results" expansion; Value / (Risk × Correction) formula; "rewind lowers Correction → raises CAIR" framing; the "users embrace AI when CAIR is high" punchline[E14]
§6 (Skills merger)Custom commands merged into Skills; .claude/commands/ keeps working; Skills are forward-looking[E6]
§6 (progressive disclosure)Three-level loading; "well-organized manual with a table of contents" metaphor[E8]
§6 (SKILL.md anatomy)Frontmatter field reference table; 1,536-char metadata cap; allowed-tools as a grant not a restriction[E6]
§6 (canonical example)The verbatim commit-message skill with allowed-tools + !-injection[E6]
Further reading footerclaude-code-best-practices framing of hooks as deterministic verification; how Anthropic teams use Claude Code for CLAUDE.md bootstrapping patterns[E9] + [E10]
Optional advanced learner pathRunnable API-side Skills notebooks[E11] + [E12]

Quiz Items → Source Mapping

Quiz IDItemSource locationConfidence
q1/cost is the API-key-mode usage monitor; on subscription, token-level cost monitoring isn't surfacedBook pp. 4 (intro), 12 (/cost is for API-key mode), 6 (subscription includes Claude Code)High
q2/clear vs /compact — clean slate vs short summaryBook p. 10 — quoted verbatim in the option textHigh
q3Stop hook failure mode — wrong command path; matcher empty "" matches all; hooks registered via /hooks not /agentsBook pp. 17–19 — the 14-step walkthrough; p. 19 "If no sound plays, revisit the hook configuration and ensure that the command path is correct" quoted in the explanationHigh
q4Upward discovery walks parent directories and combines all CLAUDE.md files; more specific takes precedenceBook pp. 24–25 — the IceBreaker example reproduced essentially verbatimHigh
q5Rewind trigger (Esc twice or /rewind); 30-day retention; bash and external edits not tracked; not a replacement for gitBook pp. 32, 36–37 — multiple short quotesHigh
q6Canonical commit-message skill with allowed-tools + !-injection; the two reasons it's stronger — (a) allowed-tools pre-approves the read-only/safe git tools without per-use prompts so anything outside the list (git push, rm) falls back to the normal permission flow (it grants, it does not restrict; hard blocks need disallowed-tools or permissions.deny); (b) retrieval-augmented context via !-injectionBook pp. 40–42 (the example and the prose argument) + [E6] (canonical reference, including the explicit "grants … does not restrict" phrasing) — synthesisHigh

Figures Referenced In Source (not reproduced in training)

FigureCaption (paraphrased)Status
3.1Claude Code authentication options screenReferenced in lesson text; image not reproduced — described in prose.
3.2Login methods for Claude Code subscription and API billingReferenced; not reproduced.
3.3Monitoring token usage with the /cost commandReferenced; described in prose (§1 monitoring sub-section).
3.4Updated token usage after running a promptReferenced; not reproduced.
3.5Viewing subscription usage with the /usage commandReferenced; described in prose (§1).
3.6Listing available slash commands in Claude CodeReferenced; replaced by the 15-row command table in §2.
3.7Claude Code settings panel with configuration optionsReferenced; described in prose (§2 settings discussion).
3.8Claude Code extension inside the Cursor editorReferenced; described in prose (§2 IDE integration sub-section).
3.9Hook configuration and security warning in Claude CodeReferenced; not reproduced.
3.10Reviewing and approving hook file changes in diff viewReferenced; described in prose (§2 diff view + §3 hook walkthrough).
3.11Cloned IceBreaker repository opened in CursorReferenced; not reproduced (the IceBreaker walkthrough is replaced by the sandbox exercise).
3.12Claude scanning repository files to generate CLAUDE.mdReferenced; described in prose (§4 /init discussion).
3.13Generated CLAUDE.md file with project overview and architecture detailsReferenced; described in prose (§4).
3.14Timeline of Claude Code releases and the rewind feature introductionReferenced; not reproduced.
3.15HooksHub landing page generated with Claude CodeReferenced; not reproduced (the HooksHub walkthrough is replaced by the sandbox landing.md exercise step).
3.16Using the /rewind command to view session history and file changesReferenced; described in prose (§5 timeline discussion).

Unsupported Or Unclear Items

ItemIssueAction
CAIR expansionBook p. 33 names the metric "Cost of AI Recovery (CAIR)". The canonical post it cites — Assaf Elovic & Harrison Chase, mid-2025 — defines the acronym as Confidence in AI Results, with formula Value / (Risk × Correction). "Cost of AI Recovery" is a fair summary of the Correction term but is not the canonical expansion.Lesson uses the canonical name ("Confidence in AI Results"), shows the formula, and explicitly notes the disagreement with the book in §5.
Book lists 3 rewind actions; current docs list 5Book p. 36 lists Restore code & conversation / Restore conversation / Restore code. [E5] documents two additional actions: Summarize from here / Summarize up to here.Lesson presents all five and flags the two summarize actions as recent additions the book doesn't cover.
Book lists 5 hook events; current docs list many moreBook p. 17 enumerates PreToolUse, PostToolUse, Notification, UserPromptSubmit, Stop. [E3] documents the full catalogue (the exact count moves with releases, so the lesson and ledger use "many more" wording rather than a hard number that could go stale).Lesson presents a focused subset (the ~10 events learners reach for first) and links to [E3] for the canonical list.
Book lists 3 settings tiers; current docs list 4Book pp. 11–12 lists User / Project / Local. [E1] adds Managed as the highest tier (cannot be overridden), with precedence Managed → CLI → Local → Project → User.Lesson presents the four-tier ladder, the precedence chain, and the permission-rule-merge exception.
Book treats /cost and /usage as two separate commandsBook pp. 4 and 7 introduce them tied to auth mode. [E2] documents them as aliases (/cost and /stats both alias /usage).Lesson surfaces the aliasing.
Book demonstrates Claude Code in Cursor onlyBook pp. 12–13 walk the learner through the Cursor extension. [E7] documents that one extension (anthropic.claude-code) serves VS Code, Cursor, and other VS Code forks via Open VSX.Lesson presents Claude Code as IDE-agnostic; the practical exercise is terminal-only.
Auto-memory subsystem (v2.1.59+) is not in the bookThe second memory subsystem — Claude-authored notes under ~/.claude/projects/<project>/memory/, indexed via MEMORY.md, toggleable via CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 — is current Anthropic-shipped behavior.Lesson covers it in §4 alongside the writer-authored CLAUDE.md tiers, with a "rules vs working notes" split-of-labor recommendation.
PDF page numbersPage references in this ledger are based on pdftotext form-feed boundaries (Chapter 3 PDF extracts to 45 form-feed pages), not printed book page numbers. The printed book may number these differently.Confidence ratings are based on PDF-page positions; cross-check with the printed book if exact pagination is required.
Subscription pricing ($20 / $100 / $200)Book p. 6 quotes Pro $20 / Max 5x $100 / Max 20x $200. These numbers move.Lesson quotes the same numbers and explicitly links to [E13] for verification of current pricing.
/vim and /pr-commentsOlder write-ups (and some tutorials) still reference these. [E2] confirms /vim is replaced by Editor mode under /config and /pr-comments was removed (just ask Claude directly).Lesson calls these out by name as removed.

Optional Enrichment

  • [E11] Anthropic cookbook — Introduction to Claude Skills and [E12] Building custom Skills for Claude. Runnable notebooks that reproduce the Skills surface on the Anthropic API side (rather than the Claude Code CLI side). Useful for advanced learners who want to author Skills that are portable between Claude Code and Anthropic-API-driven agent harnesses. Linked in Further Reading but not required for the chapter quiz or the practical exercise.
  • [E9] Best practices for Claude Code and [E10] How Anthropic teams use Claude Code. Two longer-form posts that reinforce the chapter's framings — hooks as deterministic verification, CLAUDE.md bootstrapping conventions — with internal Anthropic adoption examples. Linked in Further Reading; not assessed.
Chapter 4: Extending Claude Code with MCP Servers and Plugins

Source Ledger — Chapter 4: Extending Claude Code with MCP Servers and Plugins

Primary source (the book)

  • Source PDF: source-pdfs/04-chapter-04.pdf (45 form-feed pages in the extraction)
  • Extracted source: extracted-chapters/04-chapter-04.md (cleaned, with <!-- page N --> markers) and extracted-chapters/04-chapter-04.txt (raw, form-feed page boundaries preserved)
  • Extraction tool: pdftotext -layout -enc UTF-8 (Poppler, shipped with Git for Windows)
  • OCR needed: No — extraction was clean text.

Enrichment sources

The lesson silently incorporates material from the official Model Context Protocol specification (now hosted by the Linux Foundation), the official Claude Code MCP and plugin documentation, the Anthropic news feed, the Anthropic engineering blog, Cloudflare's CodeMode posts and Agents SDK reference, and the official MCP servers registry and the Claude Code plugin marketplace repo. Per project convention, no inline > Source: or > Enrichment — ... labels appear in the learner-facing lesson — the labels caused visual confusion in Chapter 1 and were dropped. This source ledger is the single source of provenance: every per-section mapping below tells you which paragraphs came from the book, which from labelled enrichment, and which were authored as pedagogical scaffolding for this training.

  • [E1] MCP spec — Introduction — https://modelcontextprotocol.io/introduction
  • [E2] MCP spec — Architecture — https://modelcontextprotocol.io/docs/learn/architecture
  • [E3] MCP spec — Transports — https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
  • [E4] MCP spec — Tools primitive — https://modelcontextprotocol.io/specification/2025-11-25/server/tools
  • [E5] MCP spec — Resources primitive — https://modelcontextprotocol.io/specification/2025-11-25/server/resources
  • [E6] MCP spec — Prompts primitive — https://modelcontextprotocol.io/specification/2025-11-25/server/prompts
  • [E7] Anthropic docs — Connect Claude Code to tools via MCP — https://code.claude.com/docs/en/mcp
  • [E8] Anthropic docs — Connect to MCP servers quickstart — https://code.claude.com/docs/en/mcp-quickstart
  • [E9] Anthropic docs — Create plugins — https://code.claude.com/docs/en/plugins
  • [E10] Anthropic docs — Plugins reference — https://code.claude.com/docs/en/plugins-reference
  • [E11] Anthropic docs — Plugin marketplaces — https://code.claude.com/docs/en/plugin-marketplaces
  • [E12] Anthropic docs — Discover plugins — https://code.claude.com/docs/en/discover-plugins
  • [E13] Anthropic news — Introducing the Model Context Protocol — https://www.anthropic.com/news/model-context-protocol
  • [E14] Anthropic news — Donating MCP and establishing the Agentic AI Foundation — https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
  • [E15] Anthropic engineering — Code execution with MCP: Building more efficient agents — https://www.anthropic.com/engineering/code-execution-with-mcp
  • [E16] Anthropic engineering — Effective context engineering for AI agents — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
  • [E17] Anthropic engineering — Writing effective tools for AI agents — https://www.anthropic.com/engineering/writing-tools-for-agents
  • [E18] Anthropic engineering — Equipping agents for the real world with Agent Skills — https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
  • [E19] Cloudflare blog — Code Mode: the better way to use MCP — https://blog.cloudflare.com/code-mode/
  • [E20] Cloudflare blog — Code Mode: give agents an entire API in 1,000 tokens — https://blog.cloudflare.com/code-mode-mcp/
  • [E21] Cloudflare Agents SDK — CodeMode reference — https://developers.cloudflare.com/agents/api-reference/codemode/
  • [E22] Official MCP servers registry — https://registry.modelcontextprotocol.io/
  • [E23] Official MCP reference servers — https://github.com/modelcontextprotocol/servers
  • [E24] Claude Code official plugin marketplace — https://github.com/anthropics/claude-code/blob/main/.claude-plugin/marketplace.json

This count is larger than Chapter 3's because Chapter 4's surfaces have all moved materially since the book went to print: MCP governance was donated to the Linux Foundation in December 2025 ([E14]); Anthropic published a first-party parallel to Cloudflare's CodeMode in November 2025 ([E15]); the plugin docs, plugin marketplace, and /plugin UI continue to evolve; and the public MCP registry ([E22]) did not exist when the book was written. Enrichment is used to correct and update the book rather than to add unrelated material.

Pedagogical enrichment by the training author

The following additions are not from the book and not from Anthropic or the MCP spec — they are pedagogical material written for this training. They are inventoried here so a reviewer can audit them separately. No inline labels are placed in the learner-facing lesson; only the > Analogy — ... callouts carry an in-lesson label.

  • Newcomer preface (## Before we start — MCP, hosts/clients/servers, and plugins in plain language). Defines MCP, host, MCP server, MCP client, plugin, and marketplace in plain English for readers new to agent engineering, with the governance update folded in.
  • Per-section analogies. Eight > Analogy — ... callouts, one per numbered lesson section: §1 the universal travel adapter; §2 a restaurant pass; §3 plugging in a USB device; §4 three drawers in your toolbox (rewritten from the original "house keys / office keys / visitor pass" framing after the post-build audit re-aligned §4 to the canonical local/project/user scope model); §5 a desk piled with manuals you'll never open today; §6 a walkie-talkie game of telephone; §7 from dictation to writing code; §8 an app store with a code-review pane.
  • Whole-chapter analogy (## The whole chapter in one image — the universal cable). A sustained workbench/apprentice analogy that re-frames the chapter's eight sections — protocol, three roles, install, scope, context, limitations, code-against-MCP, plugins — for less-technical readers.
  • Four SVG diagrams authored for this training (the book's figures are not reproduced — we do not have rights):
  • Figure P.1 — "MCP at a glance" (preface): host with three internal MCP clients, each connected one-to-one to a separate MCP server.
  • Figure 4.A — "The integration problem — and what MCP changes" (§1): side-by-side N×M (16 edges) vs N+M (8 edges) comparison.
  • Figure 4.B — "Context window — same project, two configurations" (§5): stacked horizontal bar chart of context allocation before (~20% MCP) and after (~2.4% MCP) --strict-mcp-config.
  • Figure 4.C — "Ping-pong vs single-shot" (§7): traditional MCP round-trip loop vs code-against-MCP single-execution shape.
  • Each figure has a figcaption that explicitly notes it is pedagogical and not from the book.
  • Conceptual activity — "Audit your current MCP setup." Ten-minute audit on the learner's own project: /mcp + /context + per-server scope, secrets, and necessity checks, plus a clean-run startup command sketch. Stretch task: design a project-shaped plugin.
  • Practical exercise — "Drive MCP scope, context, and plugins on a sandbox project." A ~30–40 minute hands-on walkthrough that takes the learner through a fresh ~/cct-ch4-exercise/ sandbox: baseline /mcp + /context, add Context7 at project scope with claude mcp add --scope project (explicit --scope project is required — claude mcp add defaults to local scope which writes to ~/.claude.json, not .mcp.json), optionally add Tavily at user scope, run a strict scoped session with --mcp-config + --strict-mcp-config and measure the context drop, install and verify a plugin from the demo Claude Code marketplace at anthropics/claude-code (distinct from the auto-loaded claude-plugins-official marketplace), then /reload-plugins and tear-down. Includes a success checklist, reflection prompts, and common pitfalls. Sandbox is created outside the training repo; nothing in the exercise modifies the training repo itself.

Quiz items and learning objectives remain grounded in the book chapter and the labelled enrichment sources — none of the pedagogical analogies, diagrams, or exercise steps are themselves assessed.

Objective → Source Mapping

Learning ObjectiveSource Section (page)EnrichmentConfidenceNotes
Explain why MCP exists (N×M problem) and the shape it imposes (hosts/clients/servers, one-client-per-server, tools/resources/prompts).Book §"Why MCP?" → "The integration problem" / "The portability challenge" / "MCP as an abstraction layer" (pp. 3–6); Book §"MCP core architecture" (pp. 6–10)[E1], [E2], [E4]–[E6], [E13]HighBook establishes the integration problem and the three roles. The three primitives (tools, resources, prompts) are named in the book as listPrompts/getPrompt/listTools/callTool/listResourceTemplates (p. 9); the lesson re-states them at a higher level using [E4]–[E6].
Add an MCP server with claude mcp add, place it at the right scope (local / project / user), audit with /mcp.Book §"Connecting Claude Code to MCP server" (pp. 14–19); Book §"MCP scope cheat sheet" (pp. 19–20)[E7], [E8]High — corrected on review. Book teaches scopes as project / user / session and uses ~/.claude/settings.json for the user-scope file path. Both are stale per [E7]: the canonical scopes are local / project / user (default is local); MCP entries live in ~/.claude.json, not ~/.claude/settings.json. The lesson uses the canonical naming end-to-end and calls out the book's older labels in a one-paragraph aside in §4.
Diagnose MCP-driven context bloat with /context, claw it back with --mcp-config + --strict-mcp-config, explain why preloaded tool descriptions are the failure mode.Book §"Context engineering in the MCP ecosystem" (pp. 20–27)[E7], [E16], [E17]HighThe 2,000 / 12,000 / ~20% breakdown is quoted directly from the book (pp. 24–25). The ~2.4% after-strict measurement is also from the book (p. 26).
Name MCP's structural limitations and explain how code-execution-against-MCP addresses them.Book §"Current limitations of MCP" (pp. 27–33); Book §"CodeMode by Cloudflare" (pp. 31–36)[E15], [E19], [E20], [E21]HighThe book covers context pollution, ping-pong execution, JSON-vs-code, and schema-shape-vs-intent (pp. 28–31). The book's CodeMode framing is Cloudflare-only; the lesson leads with Anthropic's own [E15] post (Nov 2025) which the book pre-dates, with Cloudflare as the parallel work. The ~98.7% token-reduction figure is from [E15].
Install, inspect, and run a Claude Code plugin from the official marketplace; explain what plugin.json and marketplace.json bundle.Book §"Managing configuration with Claude Code plugins" (pp. 36–44)[E9], [E10], [E11], [E12], [E24]HighBook walks through /plugin, marketplace add, source review, install, and the feature-dev worked example. The "open the source on GitHub before installing" framing is reinforced from the same security mindset the book applies to MCP servers (p. 11).

Lesson Section → Source Mapping

Lesson sectionSource locationEnrichmentConfidenceNotes
Preface — newcomer definitions of MCP, host, MCP server, MCP client, plugin, marketplaceBook pp. 2, 7–9 (definitions); Book pp. 36–37 (plugin/marketplace)[E1], [E2], [E13], [E14]HighPedagogical re-framing for newcomers. Linux Foundation governance note ([E14]) is post-book and is foregrounded here so readers don't see "Anthropic-owned MCP" framing further down without a correction.
Preface — Figure P.1 (MCP at a glance)n/a — pedagogical diagramn/an/aOriginal SVG; analogous to the book's Figs 4.9 and 4.10 but not reproduced.
§1 — N×M integration problem, Andrew Koenig quote, N+M resultBook pp. 3–6 (problem, portability challenge, abstraction layer); Andrew Koenig quote on p. 5[E1] (independent re-statement)HighKoenig quote and the fundamental-theorem-of-software-engineering framing are book-original.
§1 — Figure 4.A (N×M vs N+M visualisation)n/a — pedagogical diagramn/an/aOriginal SVG. Book's Figs 4.1–4.4 are referenced but not reproduced.
§1 — network effect, "past ten thousand public MCP servers", Linux Foundation governanceBook pp. 5–6 (network effect framing — book does not cite a server count)[E14], [E22]High — corrected on review. Book pre-dates the Dec 2025 donation; ten-thousand-server figure is from Anthropic's own donation post ([E14]). The MCP registry ([E22]) is the canonical catalogue today.
§1 — analogy: universal travel adaptern/a — pedagogical analogyn/an/aOriginal; inline > Analogy — ... callout is the only labelled in-lesson source marker per project convention.
§2 — three roles (host / MCP server / MCP client) with detailBook pp. 7–9 — quoted closely[E2]HighOne-client-per-server constraint is on book p. 9 and is the basis for quiz q1.
§2 — three primitives table (Tools / Resources / Prompts)Book p. 9 (lists listPrompts/getPrompt/listTools/callTool/listResourceTemplates)[E4], [E5], [E6]High — the book lists the methods but not the "tools vs resources vs prompts" three-primitive framing; that framing comes from [E2] and [E4]–[E6].
§2 — two transports (stdio / Streamable HTTP)Book p. 16 (mentions HTTP transport for Context7); Book p. 23 (mentions streamable HTTP at http://127.0.0.1:8000/mcp)[E3]High — corrected on review. Book does not name "stdio" explicitly or formally split the transport set; the current spec name Streamable HTTP is from [E3] (older docs say "SSE" or "HTTP").
§2 — MCP governance: introduced Nov 2024, donated to Linux Foundation Dec 2025n/a (book pre-dates)[E13], [E14]High — corrected on review. The book frames MCP as Anthropic-owned throughout; the lesson surfaces the donation.
§2 — analogy: restaurant passn/a — pedagogical analogyn/an/aOriginal.
§3 — Context7 install (steps 1–7)Book pp. 14–19 — closely followed: /mcp baseline, claude mcp add --transport http context7 https://mcp.context7.com/mcp, .mcp.json contents, restart approval, /mcp confirm, the two tools, CLAUDE.md persistence[E7], [E8]High — the lesson reproduces the book's worked example, mapped to a step-by-step shape with "Expected outcome" annotations. Correction on review: the lesson's command was updated to include --scope project explicitly because claude mcp add defaults to local scope (writes to ~/.claude.json, not .mcp.json); the book's bare command would not produce the .mcp.json the Step 3 narrative discusses.
§3 — stdio vs HTTP comparison tableBook pp. 16–17 (mentions both, npx alternative on p. 17)[E3]High — table format is pedagogical; data is from book + [E3].
§3 — analogy: plugging in a USB devicen/a — pedagogical analogyn/an/aOriginal.
§4 — MCP scope cheat sheet (canonical local / project / user)Book §"MCP scope cheat sheet" (pp. 19–20) — Table 4.1 is the basis, but the scope names are remapped to the canonical Claude Code naming (local / project / user) per [E7]. The book's "session" scope row was dropped (no such scope exists in current docs); session-only behaviour is now framed in the override-flags section below as a flag, not a scope. A "Typical content" row was added from the book's narrative bullets on p. 20.[E7], [E8]High — corrected on review. The book's older naming (project/user/session) is called out explicitly in a one-paragraph aside at the top of §4 so readers reading the book in parallel are not confused.
§4 — decision tree (local / project / user)Book p. 20 — bullet lists for each scope condensed to a three-question tree[E7]High — rewritten to use canonical scope names on review.
§4 — --mcp-config + --strict-mcp-config flag semantics (override flags, not a scope)Book pp. 25–26 — quoted; book p. 25 also notes --mcp-config accepts space-separated paths[E7]High — lesson is careful to frame these as flags-not-scopes after the scope-renaming.
§4 — API-key safety patterns (placeholders, user/local scope, --env via --mcp-config)Book pp. 23–24 (notes API keys obfuscated in the example, recommends not committing live keys)[E7]High — the three-pattern enumeration is pedagogical synthesis grounded in the book's warning. Updated to reference local and user scope by name.
§4 — analogy: three drawers in your toolboxn/a — pedagogical analogyn/an/aOriginal. Rewritten from the prior "house keys / office keys / visitor pass" framing after the canonical-scope rename made the visitor-pass image unfit (there is no temporary-pass scope).
§5 — preloaded tool descriptions consume context (the 2,000 / 12,000 / ~20% / 0% breakdown)Book pp. 24–25 — quoted directly[E16]HighVerbose math server + Context7 + Tavily + Playwright setup is the book's worked example.
§5 — Figure 4.B (context window before/after)n/a — pedagogical diagramn/an/aOriginal SVG. The book's Figs 4.28 and 4.31 are referenced but not reproduced.
§5 — Fix 1: scoped file + --strict-mcp-config (drops ~20% → ~2.4%)Book pp. 25–26 — quoted directly[E7]High
§5 — Fix 2: per-session disable from /mcp (lands at ~3.2%)Book pp. 26–27 — quoted; note: the source extraction has 3.2% MCP-related context usage is now approximately . flagged <!-- review: percentage value displaced --> — the 3.2% number is recovered from the surrounding context[E7]Medium — the displaced percentage in the extraction is the cause of the medium rating. The lesson uses the recoverable 3.2% figure with the same qualifier the book offers.
§5 — Fix 3: don't expose tools you don't use (server-author guidance)Book pp. 22–23 (verbose math server framing — "intentionally includes many MCP tools that are not required")[E17]High — extended to the "ship a few high-leverage tools" argument from [E17].
§5 — Tie-back to Chapter 1's Select strategyChapter 1 of this training (synthesis)[E16]High — pedagogical bridge across chapters.
§5 — analogy: a desk piled with manualsn/a — pedagogical analogyn/an/aOriginal.
§6 — Limitation 1: context pollution (58 tools / 55,000 tokens / GitHub+Slack+Central example)Book pp. 28–29 — quoted directly[E16], [E17]High
§6 — Limitation 2: ping-pong execution, per-call inference cost, history accumulationBook pp. 29–30 — quoted directly[E15]High
§6 — Limitation 3: JSON tool-call format is synthetic; LLMs train on code and proseBook pp. 30–31 — quoted directly; Shakespeare-Mandarin analogy on p. 33 is the book's[E15]High — the lesson does not reproduce the Shakespeare analogy (replaced by the walkie-talkie analogy) but preserves the underlying claim.
§6 — Limitation 4: schemas describe shape, not intentBook pp. 30–31 — quoted directlyn/aHigh
§6 — analogy: walkie-talkie game of telephonen/a — pedagogical analogyn/an/aOriginal; structurally similar argument to Shakespeare-Mandarin on book p. 33 but rewritten.
§7 — Code execution against MCP — Anthropic Nov 2025 post leadsn/a (book pre-dates the Anthropic post)[E15]High — corrected on review. Book covers Cloudflare CodeMode (Sep 2025) but does not cover Anthropic's Nov 2025 first-party post. Lesson leads with [E15] and the ~98.7% reduction figure from it, with Cloudflare as the parallel work.
§7 — Cloudflare CodeMode (Sep 2025) + Feb 2026 1,000-token follow-upBook §"CodeMode by Cloudflare" (pp. 31–36) — Cloudflare's framing, TypeScript API, sandbox, RPC binding[E19], [E20], [E21]High — Feb 2026 ~1,000-token figure is from [E20], not in the book.
§7 — three-bullet shape (traditional MCP / code-against-MCP / structural argument)Book pp. 31–36 (synthesis)[E15], [E19]High
§7 — Figure 4.C (ping-pong vs single-shot)n/a — pedagogical diagramn/an/aOriginal SVG. Book's Fig 4.41 is referenced but not reproduced.
§7 — caveat: "direction of travel, not yet how Claude Code runs MCP"n/a (the book does not make this caveat; it presents CodeMode as Cloudflare's Agent SDK behaviour)[E15], [E21]High — added on review. Important framing because the lesson's /mcp walkthrough in §3 still uses traditional tool-call-by-tool-call.
§7 — analogy: from dictation to writing coden/a — pedagogical analogyn/an/aOriginal.
§8 — Plugin definition + .claude-plugin/plugin.json + sub-directoriesBook pp. 36–37 — quoted closely[E9], [E10]High
§8 — Marketplace = JSON file listing plugins; /plugin UI; add marketplace by repo URLBook pp. 37–39 — quoted closely[E11], [E12], [E24]High
§8 — Two Anthropic marketplaces — official (claude-plugins-official, auto-loaded) and demo (claude-code-plugins at anthropics/claude-code, manually added)Book p. 38 (frames anthropics/claude-code as "the official Claude Code marketplace")[E12], [E24]High — corrected on review. The lesson now separates the two marketplaces with a labelled bullet pair; the book's framing conflates them. Plugin list (commit-commands, feature-dev, pr-review-toolkit, agent-sdk-dev, code-review, plugin-dev, security-guidance, frontend-design, and several more) verified against the current marketplace.json in anthropics/claude-code.
§8 — "inspect plugin source before installing" security mindsetBook pp. 39–40 — quoted; the same security mindset is applied to MCP servers on book p. 11[E9], [E12]High
§8 — Install / verify / update / uninstall / reload flowBook pp. 40–42 — quoted closely; book p. 41 says uninstall is broken — corrected on review per [E10] and [E12] which document the full lifecycle set as working. The lesson Step 5 was rewritten into a five-command lifecycle table.[E10], [E12]High — corrected on review.
§8 — Slash-command namespacing rule (/<plugin-name>:<command>)n/a (book teaches bare slash commands on p. 39)[E9], [E10]High — added on review. Canonical wording quoted in the source ledger drift table. Practical exercise updated to teach autocomplete-against-namespace-prefix rather than guessing bare commands.
§8 — feature-dev worked example (three sub-agents, discovery flow, git stash + branch switch)Book pp. 42–44 — quoted closely[E24]High — corrected on review. The command form was changed from a bare /feature-dev to "the /feature-dev: namespace prefix" because plugin commands are namespaced; the discovery-flow narrative is unchanged.
§8 — analogy: app store with a code-review panen/a — pedagogical analogyn/an/aOriginal.
Whole-chapter analogy: the universal cablen/a — pedagogical synthesisn/an/aOriginal. Ties together the eight numbered sections in one sustained workbench/apprentice analogy.
Activity: Audit your current MCP setupn/a — pedagogicaln/an/aOriginal. Designed to be completed on the learner's own machine in 10 minutes; outputs are concrete configuration moves.
Practical exercise: Drive MCP scope, context, and plugins on a sandbox projectBook §§"Connecting Claude Code to MCP server", "Context engineering in the MCP ecosystem", "Managing configuration with Claude Code plugins" (pp. 14–44) — recombined into a single hands-on sandbox flow[E7], [E8], [E12]High — original sequencing; every step is grounded in the book or the canonical docs.

Unsupported / Pedagogical-Only Claims

The following are statements in the learner-facing lesson that are not from the book and not directly from the labelled enrichment. They are listed so a reviewer can audit them in isolation.

ItemJustification
Universal-travel-adapter analogy (§1)Pedagogical analogy. No external claim.
Restaurant-pass analogy (§2)Pedagogical analogy. No external claim.
Plugging-in-a-USB-device analogy (§3)Pedagogical analogy. No external claim.
House-keys / office-keys / visitor-pass analogy (§4)Pedagogical analogy. No external claim.
Desk-piled-with-manuals analogy (§5)Pedagogical analogy. No external claim.
Walkie-talkie game-of-telephone analogy (§6)Pedagogical analogy. Replaces the book's Shakespeare-Mandarin image (book p. 33) with one that maps more directly onto the ping-pong limitation.
Dictation-vs-writing-code analogy (§7)Pedagogical analogy. No external claim.
App-store-with-a-code-review-pane analogy (§8)Pedagogical analogy. No external claim.
Whole-chapter "universal cable" analogyPedagogical synthesis. Re-states the chapter without introducing new claims.
Figure P.1 — MCP at a glanceOriginal SVG. Visually re-states book p. 9.
Figure 4.A — N×M vs N+MOriginal SVG. Visually re-states the book's portability-challenge argument (pp. 3–6) with explicit edge counts.
Figure 4.B — context-window before/afterOriginal SVG. Visually re-states the book's /context measurements (pp. 25–27).
Figure 4.C — ping-pong vs single-shotOriginal SVG. Visually re-states the book's CodeMode argument (pp. 31–36) and Anthropic's parallel [E15].
"MCP is the Select strategy from Chapter 1 applied to MCP" framing (§5)Pedagogical bridge. Maps the chapter onto the four context strategies introduced earlier in this training; not in the book.
"Direction of travel, not yet how Claude Code itself runs MCP" caveat (§7)Added by this training. The book does not flag this. Both [E15] and [E21] describe the pattern as an agent-builder option (Anthropic API, Cloudflare Agents SDK); Claude Code as of writing still runs MCP traditionally.
Conceptual activity (Audit your current MCP setup)Original pedagogical exercise.
Practical exercise (Drive MCP scope, context, and plugins on a sandbox project)Original sequencing; every step is grounded in the book or [E7]/[E8]/[E12]. Sandbox at ~/cct-ch4-exercise/ is created outside the training repo.

Quiz Item → Source Mapping

Quiz IDItemSource locationEnrichmentConfidence
q1One-client-per-server — a single MCP client cannot fan out across servers; N servers ⇒ N clients in the host.Book p. 9 — quoted closely[E2]High
q2claude --mcp-config <file> adds to inherited scopes; to load only the named file, add --strict-mcp-config.Book pp. 25–26 — quoted[E7]High
q3Scope cheat sheet (canonical local / project / user): shared staging Postgres → project; personal Slack with your token, used everywhere → user; one-off MCP server you're trying out only in this project, with credentials you don't want to commit → local.Book §"MCP scope cheat sheet" pp. 19–20 — distractor options invert two of the three assignments[E7]High — rewritten on review. Book uses older labels (project/user/session); question now uses canonical naming and the explanation flags the book's older labels explicitly.
q4Why MCP carries a context cost (tool definitions preloaded into the system prompt at session start), and the worked ~20% → ~2.4% mitigation.Book pp. 24–26 — quoted[E7], [E16], [E17]High — q4 mitigation steps are mostly book; the broader "why the protocol works this way" framing is [E16].
q5Plugins bundle skills / sub-agents / MCP servers / hooks; marketplaces list them; /plugin is the install UI; review source before installing; third-party marketplaces supported; bundle is not opaque.Book pp. 36–44 — quoted closely; third-party marketplace claim on p. 44[E9], [E11], [E12], [E24]High
q6Code-against-MCP — one inference, sandboxed run, ~98.7% token reduction, code closer to model's native distribution.Book §"CodeMode by Cloudflare" pp. 31–36 (Cloudflare framing only)[E15], [E19], [E20], [E21]High — synthesis. The ~98.7% figure is specifically from [E15] (Anthropic, Nov 2025) and is not in the book. The "direction of travel, not yet Claude Code's default" caveat is in the explanation; the correct option does not assert Claude Code already implements code-execution.

Drift / Corrections Applied

Places where the book is out of date or partly wrong, and what the lesson does about it.

DriftBook positionCurrent positionLesson treatment
MCP governanceBook frames MCP as Anthropic-introduced and Anthropic-owned throughout (pp. 3, 7, 11).MCP was donated to the Linux Foundation in December 2025 under the Agentic AI Foundation umbrella ([E14]). The spec, reference implementations, and registry now sit there.Preface and §2 surface the donation. Authoritative spec links go to modelcontextprotocol.io ([E1]–[E6]) rather than to Anthropic.
Code-execution-against-MCP — first-party postBook covers only Cloudflare's CodeMode (Sep 2025, [E19]), framed as Cloudflare's Agent SDK behaviour.Anthropic published its own "Code execution with MCP" post in November 2025 ([E15]), reporting reductions up to ~98.7% in some cases. Cloudflare followed in February 2026 with [E20] (~1,000 tokens for Cloudflare's entire 2,500+ endpoint API).§7 leads with [E15] as the first-party post, treats Cloudflare's work as the parallel earlier and later framing, and is careful to frame the pattern as "direction of travel, not yet how Claude Code itself runs MCP."
Displaced LangGraph version number in the sourceExtracted text (line ~394) reads "the latest 1.2 version of LangGraph is reported as ." with the version number missing. Flagged <!-- review: source sentence is garbled in the PDF; the version number appears displaced -->.Not recoverable from the extraction.Lesson does not quote a specific LangGraph version — the example just says "the answer reflects today's LangGraph version, not whatever was in the model's training data."
Displaced "3.2%" context-percentage value in the sourceExtracted text (line ~678) reads "3.2% MCP-related context usage is now approximately ." with the percentage displaced. Flagged <!-- review: source sentence is garbled in the PDF; percentage value appears displaced -->.Surrounding context (the book also reports ~20% → ~2.4% via --strict-mcp-config) supports the 3.2% reading for the per-session-disable case.Lesson reports the 3.2% figure for Fix 2 (per-session disable) with the same qualifier the book offers.
MCP transport namesBook mentions HTTP transport for Context7 (p. 16) and streamable HTTP at 127.0.0.1:8000/mcp (p. 23) but does not name "stdio" formally or split the transport set.Current MCP spec ([E3]) names the two transports: stdio and Streamable HTTP. Older docs sometimes called the latter "HTTP" or "SSE".§2 names both transports explicitly with the current spec terminology.
MCP config file pathBook uses ~/.claude/settings.json (p. 20) as the user-scope MCP location.Canonical docs ([E7]) put MCP entries in ~/.claude.json — not ~/.claude/settings.json (which Claude Code uses for other settings; using it for MCP is a documented common mistake). Both local and user scope MCP entries live in ~/.claude.json; the local scope is keyed under the current project's path, user is the top-level mcpServers block.§4 calls out the ~/.claude/settings.json mistake explicitly; the practical exercise was rewritten to drop the misleading "may be at either path" hint and instead instruct the learner to confirm the entry is in ~/.claude.json.
MCP scope namingBook teaches three scopes named project / user / session (p. ~16 cheat sheet and surrounding prose).Canonical Claude Code docs ([E7], [E8]) use local / project / user — there is no "session" scope. The default scope for claude mcp add (without --scope) is local, not "project for HTTP / user otherwise" as the book's flag descriptions imply. local persists across sessions; it's private-per-user-per-project, stored under the current project's path inside ~/.claude.json. Truly session-only behaviour is achieved via the --mcp-config / --strict-mcp-config flags, which are an override on top of the three-scope hierarchy, not a scope themselves.§4 was rewritten end-to-end to use the canonical names: the cheat-sheet table, the decision tree, the API-keys section, and the closing analogy were all redone. §3 Step 2 was updated to include --scope project explicitly (because without it, the default local scope writes to ~/.claude.json and the Step 3 narrative about .mcp.json would not match what the learner sees on disk). The lesson opens §4 with a one-paragraph aside that names the book's older labels and maps them to the canonical scopes, so a learner reading the book in parallel won't be confused. Quiz q3 was rewritten to use local / project / user.
Default scope for claude mcp addBook describes --scope options as project/user/session and is ambiguous about the default.Canonical CLI reference ([E7], [E8]): default is local.§3 names the default explicitly inside the breakdown of the example command. Practical exercise was patched so Step 2.1 passes --scope project and Step 3.1 passes --scope user.
"Official" plugin marketplace framingBook introduces a single "official Claude Code marketplace" at anthropics/claude-code (p. ~32).Two Anthropic marketplaces exist and are distinct ([E12]): claude-plugins-official is the official marketplace and is auto-loaded by Claude Code without needing /plugin marketplace add; claude-code-plugins at anthropics/claude-code is a demo / examples marketplace that the user adds manually.§8 separates the two with a labelled bullet pair; the practical exercise Step 5 was retitled "Install a plugin from the Anthropic demo marketplace" with an inline note about the auto-loaded official marketplace.
98.7% token-reduction attributionBook does not cover this figure (predates the post).[E15] reports a 150,000 → 2,000 token reduction (98.7%) driven by three combined effects: on-demand tool-definition loading from the filesystem (the agent reads only the tool defs it needs, instead of the host preloading all of them at session start); code execution against a typed API; and keeping intermediate tool outputs out of the prompt.§7 attributes the figure to all three drivers, not only to the last of them.
Plugin-provided slash commands are namespacedBook teaches plugin commands as bare slash commands (e.g. /feature-dev on p. 39).Canonical docs ([E9], [E10]): plugin skills are always namespaced /<plugin-name>:<skill-name> — "Plugin skills are always namespaced (like /my-first-plugin:hello) to prevent conflicts when multiple plugins have skills with the same name." The namespace prefix comes from the name field of plugin.json.§8 adds a dedicated sub-section ("Slash-command namespacing — the rule worth memorising") and rewrites the feature-dev worked example to teach /feature-dev: as a prefix to autocomplete against, not a bare command. Practical exercise Step 5.7 was rewritten to instruct the learner to type /commit-commands: and let autocomplete reveal the actual command names. A common-pitfall bullet was added.
Plugin uninstall reliabilityBook describes uninstall as broken in late-2025 builds (p. ~41) and presents it as a current limitation.Canonical docs ([E10], [E12]): uninstall is documented and reliable. The full lifecycle set is install / uninstall (aliases remove, rm) / enable / disable / update, both as /plugin <verb> in-session and claude plugin <verb> from the shell. uninstall supports --keep-data and --prune flags.§8 Step 5 was rewritten from a brief "Update or remove" paragraph into a labelled table of the five lifecycle commands with their CLI and slash-command equivalents. The book's "uninstall doesn't work" framing is preserved only as a one-line historical note (clearly labelled as book-era behavior). Practical exercise Step 6.4 now shows the working /plugin uninstall <plugin>@<marketplace> command form. The closing analogy was edited from "uninstall is (usually) one click" to "uninstall is one command."
Fine-grained component installationBook claims (p. ~44) that plugins "support fine-grained installation" — that "individual components such as a single slash command or an MCP server can be installed without installing an entire plugin."Current docs ([E12], [E9]) describe installing whole plugins from a marketplace; the /plugin detail view shows a "Will install" inventory of a plugin's commands, agents, skills, hooks, and MCP/LSP servers so you can review exactly what it adds before installing, but there is no documented way to install one component of a plugin in isolation. The plugin is the unit of installation, enable/disable, and uninstall.The lesson does not carry the book's fine-grained-install claim forward: §8 states a plugin's components are wired up and removed together as a bundle ("Install a plugin and Claude Code wires up every one of those components for you. Uninstall and they're removed together."). No quiz item asserts component-level install.
MCP servers countBook does not quote a server count.Anthropic's donation post ([E14]) cites "more than ten thousand public MCP servers" as of late 2025.§1 uses the "past ten thousand" figure with [E14] as the basis.
/reload-plugins and live-watch of .claude/Book does not cover plugin live-reload.Current [E12] documents /reload-plugins for in-session updates; full restart is only needed if .claude/ didn't exist when the session started.§8 Step 6 and the practical exercise both surface /reload-plugins.

PDF page-number caveat

Page references in this ledger are based on pdftotext form-feed boundaries (the Chapter 4 PDF extracts to 45 form-feed pages), not printed book page numbers. The printed book may number these differently. Confidence ratings are based on PDF-page positions; cross-check with the printed book if exact pagination is required.

Chapter 5: Automating Your Development Workflow with Claude Code and GitHub

Source Ledger — Chapter 5: Automating Your Development Workflow with Claude Code and GitHub

Primary source (the book)

  • Source PDF: source-pdfs/05-chapter-05.pdf
  • Extracted source: extracted-chapters/05-chapter-05.md (cleaned, with approximate <!-- page N --> markers — 8 of them) and extracted-chapters/05-chapter-05.txt (raw extraction)
  • Extraction tool: pdftotext -layout -enc UTF-8 (Poppler, shipped with Git for Windows)
  • OCR needed: No — extraction was text, but see the PDF page-number caveat at the end. The Chapter 5 extraction lacked clean form-feed page boundaries, so page markers and references in this ledger are approximate.
  • Book's three main sections: "Installing and configuring the Claude Code GitHub integration" (pp. ~1–4), "Using Claude Code to resolve GitHub issues" (pp. ~4–6), and "Adding repository context with CLAUDE.md" (pp. ~7–8).

Enrichment sources

The lesson silently incorporates material from the official Claude Code documentation (GitHub Actions, code review, authentication, best practices, headless mode, the Claude Agent SDK, and memory/CLAUDE.md), Anthropic's blog, the anthropics/claude-code-action GitHub repository (its example workflows and security doc), and the official GitHub Actions documentation (workflows, events, secrets, and the GitHub-App-vs-OAuth-app distinction). Per project convention, no inline > Source: or > Enrichment — ... labels appear in the learner-facing lesson — the labels caused visual confusion in Chapter 1 and were dropped. This source ledger is the single source of provenance: every per-section mapping below tells you which paragraphs came from the book, which from labelled enrichment, and which were authored as pedagogical scaffolding for this training.

  • [E1] Anthropic docs — Claude Code GitHub Actions — https://code.claude.com/docs/en/github-actions
  • [E2] Anthropic docs — Code review — https://code.claude.com/docs/en/code-review
  • [E3] Anthropic docs — Authentication / long-lived token — https://code.claude.com/docs/en/authentication
  • [E4] Anthropic docs — Claude Code best practices — https://code.claude.com/docs/en/best-practices
  • [E5] Anthropic docs — Headless mode — https://code.claude.com/docs/en/headless
  • [E6] Anthropic docs — Claude Agent SDK overview — https://code.claude.com/docs/en/agent-sdk/overview
  • [E7] Anthropic docs — Memory / CLAUDE.md — https://code.claude.com/docs/en/memory
  • [E8] Anthropic blog — How Anthropic teams use Claude Code — https://claude.com/blog/how-anthropic-teams-use-claude-code
  • [E9] GitHub Action — anthropics/claude-code-action repo — https://github.com/anthropics/claude-code-action
  • [E10] GitHub Action — example workflows — https://github.com/anthropics/claude-code-action/tree/main/examples
  • [E11] GitHub Action — security model — https://github.com/anthropics/claude-code-action/blob/main/docs/security.md
  • [E12] GitHub docs — About workflows — https://docs.github.com/en/actions/concepts/workflows-and-actions/about-workflows
  • [E13] GitHub docs — Events that trigger workflows — https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
  • [E14] GitHub docs — Using secrets in GitHub Actions — https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets
  • [E15] GitHub docs — GitHub Apps vs OAuth apps — https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/differences-between-github-apps-and-oauth-apps

Enrichment is unusually load-bearing in this chapter because the GitHub-integration surface has moved materially since the book went to print: the action GA'd to @v1 (the book shows @beta), the beta mode: "tag" / mode: "agent" vocabulary and inputs were removed in favour of a single auto-detecting action, the branch name is now a configurable input whose default differs from the book's slash form, the action's example claude.yml listens on more events than the book shows (while the docs' inline "basic workflow" shows fewer), and the action's default behaviour (push-a-branch-and-PR-link, no auto-merge) needs reconciling with the book's "Claude creates a pull request" narrative. The enrichment is used primarily to correct and update the book — see the Drift / Corrections Applied table, which is the most important section of this ledger for Chapter 5. A 2026-06-14 accuracy re-audit (see the drift table) softened several over-claims: the workflow is presented as representative, not canonical; gh is useful, not a required prerequisite for /install-github-app; the two-template chooser and claude-code-review.yml are framed as book-era rather than guaranteed current installer output; the branch suffix is framed as a configurable default; and a dated June-15-2026 subscription-billing caveat was added.

Pedagogical enrichment by the training author

The following additions are not from the book and not from Anthropic or GitHub docs — they are pedagogical material written for this training. They are inventoried here so a reviewer can audit them separately. No inline labels are placed in the learner-facing lesson; only the > Analogy — ... callouts carry an in-lesson label.

  • Newcomer preface (## Before we start — GitHub Actions, workflows, and two kinds of auth in plain language). Defines GitHub Actions, event, workflow, job, step, action (the reusable unit), runner, secret, and the two-credentials distinction (GitHub App vs model credential) in plain English for readers new to CI/CD, plus a smallest-well-formed-workflow YAML example and a note on the issue/PR objects. Grounded in [E12]–[E15] and [E9]; the two-credentials framing is the chapter's central conceptual scaffold.
  • Per-section analogies. Seven > Analogy — ... callouts, one per numbered lesson section: §1 the contractor who works after hours; §2 the dispatch desk (event = call, workflow = standing instruction sheet, runner = dispatched truck, action = specialist, two badges = two credentials); §3 onboarding a new hire (gh login = front-desk ID, App = building badge, model credential = payroll, secret store = locked drawer); §4 the eager intern and the load-bearing label; §5 everyone gets a photocopy of the blueprints; §6 the runbook on the wall; §7 the QA bench with its own checklist.
  • Whole-chapter analogy (## The whole chapter in one image — the contractor with a key to the shop). A sustained contractor/after-hours analogy that re-frames the chapter's seven sections — install, architecture, the break, branch-per-issue, the CLAUDE.md fix, and the review gate — for less-technical readers.
  • Four SVG diagrams authored for this training (the book's figures are not reproduced — we do not have rights):
  • Figure P.1 — "Anatomy of a GitHub Actions run" (preface): event → workflow → job-on-runner → steps → result, with a note that secrets are referenced, never written.
  • Figure 5.A — "The Claude-on-GitHub loop" (§2): @claude comment → claude.yml → ephemeral runner → claude-code-action@v1 → Claude Code (headless, Agent SDK), with the two independent credentials feeding in and the human-merges-not-Claude endpoint.
  • Figure 5.B — "Why the rename broke" (§4): local variable → JSON payload → third-party API, before (keys match, accepted) vs after the rename (required key missing, rejected).
  • Figure 5.C — "Same issue, two runs" (§6): Run 1 (no CLAUDE.md, broken integration) vs Run 2 (committed CLAUDE.md with the contract gotcha, correct change), side by side.
  • Each figure has a figcaption that explicitly notes it is pedagogical and not from the book.
  • "Interactive vs automated" comparison table (§1). Six-row table (where it runs / what starts it / who watches / permission prompts / course-correction / the safety net) contrasting Chapters 1–4's interactive use with this chapter's unattended use. Pedagogical synthesis; the headless "process terminates at a permission boundary" row is grounded in [E5].
  • Conceptual activity — "Write the CLAUDE.md lines that would stop a 2 a.m. mistake." Ten-minute individual exercise: list 3–5 load-bearing facts an autonomous agent would get wrong, write the single CLAUDE.md line for each, decide which need hard enforcement (test/hook) vs advisory context, and trim to 8–10 lines. Includes a stretch task sketching a PR-review workflow (a learner-named copy of one of the action's pr-review-*.yml examples) with one --system-prompt line and one --allowedTools "Bash(…)" entry.
  • Practical exercise — "Drive the autonomous loop and prove that context fixes it." A ~35–45 minute hands-on walkthrough with two tracks: Track A wires the real GitHub integration (/install-github-app, the App, the model credential, @claude on an issue, review the claude/issue-… branch without merging); Track B reproduces the chapter's central finding entirely locally with no GitHub account — a tiny repo with a load-bearing payload key, run claude -p headless (the same non-interactive mode the Action uses) without CLAUDE.md (reproduce the break), then with CLAUDE.md (fix it), then a pytest contract check that passes on the good change and fails on the stashed broken one. Includes a success checklist and common pitfalls. Sandbox is created at ~/cct-ch5-lab/, outside the training repo.

Quiz items and learning objectives remain grounded in the book chapter and the labelled enrichment sources — none of the pedagogical analogies, diagrams, the comparison table, the activity, or the exercise steps are themselves assessed.

Objective → Source Mapping

Learning ObjectiveSource Section (page)EnrichmentConfidenceNotes
Explain how Claude Code runs inside GitHub Actions (event → workflow → claude-code-action@v1 on an ephemeral runner → headless Claude Code on the Agent SDK) and name the two independent credentials (GitHub App for repo access; OAuth token/API key as a secret for model auth).Book §"Installing and configuring..." (pp. ~1, 3–4) — establishes GitHub Actions as event-driven, the workflow files, and that the token is a secret[E1], [E5], [E6], [E9], [E12]–[E15]High — corrected on review. Book shows @beta and a single-event issue_comment excerpt; the lesson uses @v1 and a representative multi-event example workflow (the action's examples/claude.yml currently lists four events; the docs' inline basic workflow shows two — presented as representative, not canonical) per [E1]/[E9]. The SDK was the "Claude Code SDK" in the book era (book p. ~1: "Claude Code SDK"); the lesson uses "Claude Agent SDK" per [E6] and notes the rename. The two-credentials separation is sharpened from the book's looser "the token is a secret" framing using [E9], [E11], [E15].
Install and configure the integration by running /install-github-app from Claude Code (the documented path; gh useful but not required), install the App, choose a model credential, and merge the PR it opens to add an @claude assistant workflow (claude.yml).Book §"Installing and configuring..." (pp. ~1–4) — closely followed: /git → /install-github-app, gh install/auth, App install, two templates, auth choice, the setup PR adding the YAML files[E1], [E3], [E9]High — corrected on review. Lesson presents /install-github-app as a standalone command (book reaches it via /git); frames gh as useful-not-required (current docs list no gh prerequisite for /install-github-app); frames the two-template chooser + claude-code-review.yml as book-era (current docs describe the App + an @claude claude.yml; PR-review workflows are copied in from the examples); uses lowercase .yml (book OCR: .YAML). See drift table.
Trigger Claude with @claude, describe the branch-per-issue model (a separate branch under the configurable claude/ prefix, never main; default template yields claude/issue-<number>-<timestamp>) and the default human-in-the-loop safeguard (push a branch + PR link; human reviews/merges).Book §"Using Claude Code to resolve GitHub issues" (pp. ~4–6) — @claude mention, branch naming, never touches main, full control over review/modify/merge[E1], [E9], [E11]High — corrected on review. Branch naming is a configurable input (branch_prefix default claude/; branch_name_template default {{prefix}}{{entityType}}-{{entityNumber}}-{{timestamp}}); the guaranteed part is "a separate branch under claude/, not main," and the book's claude/issue/<number> slash form is noted as older. The book says Claude "automatically creat[es] a pull request"; the action's security doc ([E11]) says the default is push-a-branch + PR-creation link, no auto-open/merge. Lesson reconciles.
Diagnose why an autonomous agent introduces a breaking change without repository context — the third-party-API-contract example and the trust-then-verify gap — and explain why reviewing agent output is non-negotiable.Book §"Using Claude Code to resolve GitHub issues" → "Reviewing the proposed changes" / "Understanding Claude's workflow" (pp. ~5–6) — the rename breaks the third-party contract; "review any changes carefully rather than accepting them blindly... applies throughout all agentic workflows"[E4], [E11]HighThe book carries the failure narrative and the review-carefully principle verbatim. The trust-then-verify gap naming and "if you can't verify it, don't ship it" wording are from [E4], not the book.
Use /init to generate and commit a CLAUDE.md, and explain why committed context improves accuracy for automated runs where no human can course-correct.Book §"Adding repository context with CLAUDE.md" (pp. ~7–8) — /init scans and writes CLAUDE.md; permission whitelist to .claude/settings.local.json; commit so it's "versioned, shared with the team, and available to Claude Code when running in automated workflows"[E4], [E7], [E1]HighThe "available during the automated run on the runner" point is the book's; the "advisory, not a hard guarantee; keep it short" caveats and the "persistent context Claude can't infer from code alone" / "common gotchas" framing are from [E4]/[E7].
Describe the layered safety model for autonomous Claude-on-GitHub — scoped App permissions, only-write-access-can-trigger, short-lived repo-scoped tokens, prompt-injection caution, a configurable review workflow, and branch protection — and explain how each compensates for the loss of interactive oversight.Book §§"Creating the pull request" (security note, p. ~4), "Inspecting Claude's changes" (review system "fully configurable", p. ~8)[E1], [E2], [E4], [E11]High — synthesis. The book gives "token stored as a secret," "only users with appropriate access can trigger," and "fully configurable" review; the only-write-access rule, short-lived repo-scoped token, prompt-injection caution, and branch-protection backstop are from [E11]/[E1]. The fresh-context-reviewer argument is from [E4].

Lesson Section → Source Mapping

Lesson sectionSource locationEnrichmentConfidenceNotes
Preface — GitHub Actions / event / workflow / job / step / action / runner / secret definitions, smallest-workflow YAML, two-credentials framing, issue/PRBook p. ~1 (GitHub Actions is "serverless," event-driven, YAML workflow files); Book p. ~4 (token stored as a secret)[E12], [E13], [E14], [E15], [E9]HighPedagogical re-framing for newcomers. The "action (the reusable unit) vs GitHub Actions (the platform)" distinction, the fork-secrets property, and the GitHub-App-vs-PAT-vs-OAuth distinction are from [E12]–[E15]; the book does not draw them out.
Preface — Figure P.1 (Anatomy of a GitHub Actions run)n/a — pedagogical diagram[E12]n/aOriginal SVG. Visualises the generic Actions pipeline; not a reproduction of any book figure.
"Why this chapter matters" — the shift from interactive to unattended; Anthropic Product Design team exampleBook p. ~1 (integration "already used in real-world production systems"; Anthropic uses it across open-source repos)[E8]High — corrected on review. The book's specific public example link (anthropics/skills/actions) is not used (it currently shows Copilot review runs — see drift table); the lesson cites the Product Design team's automated PR-comment workflow from [E8] instead.
§1 — interactive vs automated comparison table; "no one to ask" / headless terminates at a permission boundaryBook pp. ~1, 5–6 (the chapter's motivating contrast, implicit)[E5]High — table is pedagogical synthesis; the "process terminates at a permission boundary" row is grounded in [E5] (headless mode).
§1 — analogy: the contractor who works after hoursn/a — pedagogical analogyn/an/aOriginal; inline > Analogy — ... callout is the only labelled in-lesson source marker per project convention.
§2 — the mechanical loop (event → claude.yml → ephemeral runner → claude-code-action@v1 → headless Claude on the Agent SDK → branch → PR, human merges)Book p. ~1 (event-driven, workflows run on GitHub Actions, "Claude Code CLI and the Claude Code SDK"); Book p. ~4[E1], [E5], [E6], [E9]High — corrected on review. "Claude Agent SDK" replaces book's "Claude Code SDK" per [E6]. The @v1 action and single auto-detecting action (no mode:) per [E1]/[E9]. The "example workflows listen on more than one event" point per [E1]/[E10] — framed as representative, not canonical. The "human merges, not Claude" endpoint per [E11].
§2 — Figure 5.A (the Claude-on-GitHub loop)n/a — pedagogical diagram[E9], [E11]n/aOriginal SVG. Encodes the two-credentials separation and the human-merges endpoint.
§2 — "details the book's example simplifies" (the @v1 tag, single unified action, more-than-one-event template)Book p. ~4 (@beta, single issue_comment event)[E1], [E9]High — corrected on review. Each correction is in the drift table.
§2 — analogy: the dispatch deskn/a — pedagogical analogyn/an/aOriginal.
§3 — /install-github-app (standalone); Step 1 gh (optional, not a prerequisite); Step 2 App install; Step 3 the workflow it sets up (@claude assistant claude.yml; review added separately); Step 4 model credential (+ June-15-2026 billing caveat); Step 5 setup PR + a representative claude.ymlBook §"Installing and configuring..." (pp. ~1–4) — closely followed step-by-step[E1], [E3], [E9]High — corrected on review. Lesson presents /install-github-app standalone (book: via /git) and frames gh as useful-not-required (current docs list no gh prerequisite). The displayed claude.yml is labelled representative, not canonical — close to the action's examples/claude.yml (multi-event, @v1, least-privilege permissions:, if: mention guard) — with a pointer to verify the live examples. Step 3 frames the book's two-template chooser ("Tag Claude" / "Claude Code Review") as book-era; current docs describe the App + an @claude claude.yml, with PR-review workflows copied in from the examples. Windows/Linux gh install commands added for cross-platform learners (book shows macOS Homebrew only).
§3 — App permission scope (read & write on Contents, Issues, Pull requests)Book p. ~3 (App "allows Claude to comment, create pull requests, and solve issues")[E1], [E9], [E15]High — the specific Contents/Issues/Pull-requests scope is from [E1]/[E9]; the book describes the capability, not the exact permission set.
§3 — model credential: OAuth token (claude setup-token, sk-ant-oat01-…, ~1yr, secret CLAUDE_CODE_OAUTH_TOKEN) vs API key (ANTHROPIC_API_KEY); aside on Bedrock/Vertex/Foundry/WIFBook p. ~3 (long-lived token vs API key; subscription vs large-scale framing)[E3]High — corrected on review. The token format, claude setup-token command, validity, and the Bedrock/Vertex/Foundry/WIF aside are from [E3]; the book covers only the two primary paths.
§3 — workflow filenames, lowercase .ymlBook pp. ~3–4 (book OCR shows claude.YAML / claude-code-review.YAML)[E1], [E9]High — corrected on review. Lesson uses lowercase .yml and notes the uppercase .YAML is an OCR artifact. It also notes a dedicated review workflow (pr-review-*.yml from the examples) is copied in separately rather than being a guaranteed installer output named claude-code-review.yml (book-era).
§3 — Step 4 subscription-token billing caveat (June 15, 2026 Agent SDK credit)n/a (book pre-dates)[E3], [E5]High — added on 2026-06-14 re-audit. Per [E3]/[E5], starting June 15, 2026, Agent SDK / claude -p usage on subscription plans draws from a separate monthly Agent SDK credit; the lesson adds an "as of writing, verify current terms" caveat at the claude setup-token step and in Further Reading.
§3 — analogy: onboarding a new hiren/a — pedagogical analogyn/an/aOriginal.
§4 — @claude mention fires the workflow; run gets a human-readable name; watch the issue not the raw JSON logs; Claude looks for CLAUDE.md first; repo has none (deliberate)Book §"Using Claude Code to resolve GitHub issues" (pp. ~4–5) — quoted closely: the "small rename" run name, JSON-logs-vs-issue-view, the to-do list, the missing CLAUDE.md spoiler[E1]HighClosely follows the book's worked IceBreaker example.
§4 — Claude pushes a branch and surfaces a PR-creation link (default config, human-in-the-loop)Book p. ~6 (book says Claude "creat[es] a pull request")[E11]High — corrected on review. Reconciled per [E11]: default is push-branch + PR link, not auto-open/merge. See drift table.
§4 — the rename breaks a third-party API contract (the load-bearing payload key)Book §"Reviewing the proposed changes" (pp. ~5–6) — quoted: variable is part of a payload to a third-party service that requires a specific key set; rename breaks the contractn/aHighCore book narrative, preserved faithfully.
§4 — Figure 5.B (why the rename broke)n/a — pedagogical diagramn/an/aOriginal SVG. Visualises the book's Figs 5.6/5.7 argument; not reproduced.
§4 — the trust-then-verify gap; "if you can't verify it, don't ship it"; "review carefully, applies to every agentic workflow"Book p. ~5 ("review any changes carefully... applies throughout all agentic workflows")[E4]High — the review-carefully principle is the book's; the trust-then-verify gap naming and the verification quotes are from [E4].
§4 — analogy: the eager intern and the load-bearing labeln/a — pedagogical analogyn/an/aOriginal.
§5 — branch-per-issue model (a separate branch under the configurable claude/ prefix, never main); foundation for parallelism / Git worktreesBook §"Understanding Claude's workflow" (p. ~6) — branch convention, never touches main, full control, parallel instances, worktrees later[E1], [E9]High — corrected on review. Branch naming framed as a configurable input (branch_prefix default claude/; default template yields claude/issue-<number>-<timestamp>); the reliable claim is "a separate branch under claude/, not main," and the book's claude/issue/<number> slash form is noted as older. Lesson warns against hard-coding an exact suffix.
§5 — security model around triggering (only write-access can trigger; bots blocked; short-lived repo-scoped token; prompt-injection caution on untrusted content)Book p. ~4 ("Only users with the appropriate repository access can trigger the workflow")[E1], [E11]High — corrected/extended on review. The book gives the access-gating sentence; the bots-blocked-by-default, short-lived-repo-scoped-token, and prompt-injection-on-untrusted-content points are from [E11].
§5 — analogy: everyone gets a photocopy of the blueprintsn/a — pedagogical analogyn/an/aOriginal.
§6 — Step 1 /init scans and writes CLAUDE.md; permissions whitelisted to .claude/settings.local.jsonBook §"Initializing the repository context" (p. ~7) — quoted closely[E7]High
§6 — Step 2 review and add the one load-bearing line (the contract gotcha); "persistent context Claude can't infer from code alone" / "common gotchas"Book §"Reviewing and committing CLAUDE.md" (p. ~7)[E4], [E7]High — the gotcha-line framing is pedagogical synthesis grounded in [E4]/[E7]; the book describes reviewing the auto-generated summary but does not name the specific load-bearing line to add.
§6 — Step 3 commit it (versioned, shared, available in GitHub Actions); "Claude respects your CLAUDE.md guidelines"Book p. ~7 ("versioned, shared with the team, and available to Claude Code when running in automated workflows, such as GitHub Actions")[E1], [E7]High — the "Claude respects your CLAUDE.md guidelines and existing code patterns" quote is from [E1].
§6 — Step 4 re-tag (with the function hint, biased-but-illustrative); consistent rename preserving the payload keyBook §"Inspecting Claude's changes" (p. ~8) — quoted closely, including the biased-experiment admission and the function hint[E1]High
§6 — Figure 5.C (same issue, two runs)n/a — pedagogical diagramn/an/aOriginal SVG. Visualises the book's run-1-vs-run-2 contrast.
§6 — "why context matters more for automated than interactive runs"; CLAUDE.md is advisory, keep it shortBook p. ~8 (context improves accuracy)[E4], [E7]High — the advisory-not-a-guarantee and keep-it-short caveats are from [E4]/[E7], added by this training; the book does not flag them.
§6 — analogy: the runbook on the walln/a — pedagogical analogyn/an/aOriginal.
§7 — an automated PR-review workflow (copied in from the action's pr-review-*.yml examples) runs on PR open; "fully configurable"; prompt + claude_args knobs (run tests/linters, pin model, --max-turns, inject criteria via --system-prompt)Book §"Inspecting Claude's changes" (p. ~8) — "This review system is fully configurable. Additional checks, such as linters, test execution, or custom validation rules, can be added"[E1], [E2], [E10]High — corrected/extended on review. The book states "fully configurable" generically and installs review as a second template; the lesson frames PR review as a workflow you add from the examples (e.g. pr-review-comprehensive.yml), and the v1 prompt / claude_args model with the specific --allowedTools / --model / --max-turns / --system-prompt examples are from [E1] (the beta mode: inputs were removed — see drift table).
§7 — fresh-context reviewer argument ("Claude won't be biased toward code it just wrote")n/a (book does not make this argument)[E4]High — added on review. Direct quote from [E4].
§7 — distinction: self-hosted review workflow (pr-review-*.yml) vs Anthropic's managed Code Review product (research preview, Team/Enterprise, run on Anthropic infra, ~$15–25/review, bidirectional CLAUDE.md checks)n/a (book does not cover the managed product)[E2]Medium — added on review. The managed Code Review product details (research-preview status, plan-gating, infra, per-review cost, bidirectional CLAUDE.md flagging) are from [E2]; product surface for a preview feature is the kind that moves between releases, hence Medium.
§7 — branch-protection rules as the deterministic backstopn/a (book does not cover branch protection)[E1], [E11]High — added on review. GitHub branch-protection is GitHub-native; the "Claude's review is advice; branch protection is the gate" framing is this training's synthesis grounded in [E1]/[E11]'s least-privilege/human-in-the-loop guidance.
§7 — analogy: the QA bench with its own checklistn/a — pedagogical analogyn/an/aOriginal.
Whole-chapter analogy: the contractor with a key to the shopn/a — pedagogical synthesisn/an/aOriginal. Ties the seven numbered sections into one sustained contractor/after-hours analogy.
Activity: Write the CLAUDE.md lines that would stop a 2 a.m. mistaken/a — pedagogical[E4], [E7]n/aOriginal. Ten-minute individual exercise on the learner's own repo; grounded in the §4/§6 lesson and the CLAUDE.md-as-gotchas guidance in [E4]/[E7].
Practical exercise: Drive the autonomous loop and prove that context fixes it (Track A real integration + Track B local headless lab)Book §§"Installing and configuring...", "Using Claude Code to resolve GitHub issues", "Adding repository context with CLAUDE.md" (pp. ~1–8) — recombined into a two-track hands-on flow[E1], [E5]High — original sequencing. Track B uses claude -p headless ([E5]) and a pytest contract check to reproduce the book's break-then-fix locally without GitHub. Sandbox at ~/cct-ch5-lab/ is outside the training repo.

Unsupported / Pedagogical-Only Claims

The following are statements in the learner-facing lesson that are not from the book and not directly from the labelled enrichment. They are listed so a reviewer can audit them in isolation.

ItemJustification
Contractor-who-works-after-hours analogy (§1)Pedagogical analogy. No external claim.
Dispatch-desk analogy (§2)Pedagogical analogy. No external claim.
Onboarding-a-new-hire analogy (§3)Pedagogical analogy. No external claim.
Eager-intern-and-the-load-bearing-label analogy (§4)Pedagogical analogy. Restates the book's third-party-contract break with a non-code image.
Everyone-gets-a-photocopy-of-the-blueprints analogy (§5)Pedagogical analogy. Restates the branch-per-issue model.
The-runbook-on-the-wall analogy (§6)Pedagogical analogy. Restates the committed-CLAUDE.md fix.
The-QA-bench-with-its-own-checklist analogy (§7)Pedagogical analogy. Restates the independent-reviewer + branch-protection point.
Whole-chapter "contractor with a key to the shop" analogyPedagogical synthesis. Re-states the chapter without introducing new claims.
Figure P.1 — Anatomy of a GitHub Actions runOriginal SVG. Visually re-states the generic Actions pipeline ([E12]).
Figure 5.A — the Claude-on-GitHub loopOriginal SVG. Visually re-states the §2 mechanical loop with the two-credentials separation.
Figure 5.B — why the rename brokeOriginal SVG. Visually re-states the book's Figs 5.6/5.7 contract-break argument.
Figure 5.C — same issue, two runsOriginal SVG. Visually re-states the book's run-1-vs-run-2 contrast.
"Interactive vs automated" comparison table (§1)Pedagogical synthesis across Chapters 1–4 and this chapter. The headless-terminates-at-a-permission-boundary row is grounded in [E5].
"The safety that was 'you, watching' has to move somewhere else" framing (§1, recurring)Pedagogical thesis of the chapter. Synthesises the book's review-carefully principle with the layered safety model; not a single book sentence.
"Claude Agent SDK" rename note (§2)Grounded in [E6]; surfaced as a correction to the book's "Claude Code SDK." Listed here because the rename itself is enrichment-sourced, not book-sourced.
Conceptual activity (Write the CLAUDE.md lines that would stop a 2 a.m. mistake)Original pedagogical exercise; grounded in the §4/§6 lesson and [E4]/[E7].
Practical exercise (Drive the autonomous loop), both tracksOriginal sequencing; every step is grounded in the book or [E1]/[E5]. Track B sandbox at ~/cct-ch5-lab/ is created outside the training repo. The linkedin.py / issue.md / test_contract.py sandbox files are authored for this training.

Quiz Item → Source Mapping

Quiz IDItemSource locationEnrichmentConfidence
q1How you trigger Claude on an issue (@claude mention) and the mechanism (the comment is an issue_comment event matching the on: block of claude.yml, which runs anthropics/claude-code-action@v1 headless on an ephemeral runner).Book pp. ~1, 4–5 (event-driven workflow, @claude mention)[E1], [E5], [E9]High — the @v1 action name and the headless-runner mechanism are from [E1]/[E5]/[E9]; the explanation also surfaces the write-access trigger gate ([E11]).
q2Why the rename was wrong (load-bearing payload key in a third-party contract; renaming broke it) and the stated takeaway (review carefully, never blindly; applies to every agentic workflow). Distractor d ("committed to main") is wrong on the facts — Claude worked on its own branch.Book pp. ~5–6 — quoted closely[E4]High — the trust-then-verify-gap framing in the explanation is from [E4]; the core claim is the book's.
q3How Claude applies changes (a separate auto-created branch under the configurable claude/ prefix, never main) and why it's foundational for scaling (isolated branches → parallel Claude instances → Git worktrees later).Book p. ~6 — quoted; branch-naming reframed[E1], [E9]High — corrected on 2026-06-14 re-audit. Option b and the explanation now lead with "a separate branch under the claude/ prefix"; the claude/issue-<number>-<timestamp> form appears only as the configurable default template, with the book's older claude/issue/<number> slash form noted and a warning against hard-coding an exact suffix.
q4What /init does (scans repo, writes CLAUDE.md of stack/structure/conventions) and why committing it helps automated runs (the runner reads the committed file; gives the agent repo-specific facts it can't infer — the "don't rename this payload key" gotcha).Book pp. ~7–8 — quoted closely[E1], [E7]High
q5How the model credential is handled (stored as a GitHub Actions secret, set up automatically, referenced ${{ secrets.… }}, never inline) and the two options (OAuth token CLAUDE_CODE_OAUTH_TOKEN via claude setup-token; API key ANTHROPIC_API_KEY).Book pp. ~3–4 — quoted[E3], [E14]High — the explanation's Bedrock/Vertex/Foundry aside is from [E3]; the secret-handling mechanics from [E14].
q6Synthesis: how the layered safety model compensates for lost live oversight — committed context substitutes for live correction; scoped/short-lived/repo-only App token; only write-access can trigger; untrusted content = prompt-injection risk; a review gate (fresh-context reviewer + real tests via claude_args + branch protection); no auto-merge by default.Book pp. ~4, 8 (token-as-secret, access-gating, "fully configurable" review)[E1], [E2], [E4], [E11]High — synthesis. The only-write-access rule, short-lived repo-scoped token, prompt-injection caution, fresh-context-reviewer argument, and no-auto-merge default are enrichment-sourced ([E11]/[E4]/[E1]); the book supplies the skeleton. This is the chapter's one enrichment-grounded synthesis question.

Drift / Corrections Applied

Places where the book is out of date or partly wrong, and what the lesson does about it. This is the most important section for Chapter 5 — the book is materially stale on the GitHub-integration surface, which moved to a GA'd @v1 action after the book went to print. Each row is verified against the current canonical docs ([E1], [E3], [E5], [E9], [E11]). Re-audited 2026-06-14 against examples/claude.yml, action.yml, usage.md, the github-actions / authentication / headless / code-review docs, and the examples/ directory listing — this pass softened several over-claims (representative-not-canonical workflow; gh not a required prerequisite; book-era two-template chooser; configurable branch suffix) and added the gh-prerequisite and June-15-2026 billing rows.

DriftBook positionCurrent positionLesson treatment
Action versionBook's workflow YAML uses uses: anthropics/claude-code-action@beta (p. ~4).The action GA'd to @v1 (released 2025-08-26). @beta is an earlier build.§2 and §3 use anthropics/claude-code-action@v1 throughout; §2's "details the book simplifies" bullet states the @beta tag is from an earlier build. Quiz q1 names @v1.
Branch naming conventionBook writes the branch as claude/issue/<issue-number> (p. ~6), presented as the convention.Branch naming is a configurable input: branch_prefix defaults to claude/, and branch_name_template defaults to {{prefix}}{{entityType}}-{{entityNumber}}-{{timestamp}} (yielding claude/issue-<number>-<timestamp>, e.g. claude/issue-950-20250711_082715) per the action's action.yml. The user-facing docs/README/usage.md say nothing about branch naming. The slash form claude/issue/<number> is not used by current tooling.Re-audited 2026-06-14. §5 and quiz q3 now teach "a separate branch under the configurable claude/ prefix, never main" as the reliable claim; the claude/issue-<number>-<timestamp> form is shown only as the default template output, with both the prefix and template called out as configurable and a warning not to hard-code an exact suffix. The book's slash form is noted as older.
Install templates / review workflowBook describes the installer presenting a two-template chooser — "Tag Claude" and "Claude Code Review" — and says it creates claude.YAML + claude-code-review.YAML (pp. ~3–4).Current docs ([E1]) do not describe a template chooser or a claude-code-review.yml filename. /install-github-app sets up the App + required secret and an @claude assistant workflow (claude.yml); the manual fallback copies a single examples/claude.yml. Automated PR review is a separate workflow you copy from the examples (pr-review-comprehensive.yml, pr-review-filtered-paths.yml, manual-code-analysis.yml — there is no claude-code-review.yml in examples/). "Tag Claude" reflects the removed beta mode: "tag" vocabulary.Re-audited 2026-06-14. §3 Step 3 now frames the two-template chooser and the claude-code-review.yml filename as the book's (book-era) description, states current /install-github-app sets up the App + @claude claude.yml, and tells the learner PR-review workflows are copied in from the examples. §3 Step 5 and §7 are aligned. The activity stretch task now sketches a learner-named PR-review workflow (from the pr-review-*.yml examples) — its earlier claude-code-review.yml filename was removed so the term isn't read as an installer output.
Workflow file extension casingBook OCR shows the filenames as claude.YAML / claude-code-review.YAML (pp. ~3–4).Workflow files are lowercase .yml — e.g. the assistant claude.yml and the example review workflows (pr-review-comprehensive.yml, etc.). The uppercase .YAML is an OCR artifact; the name claude-code-review.yml specifically is the book's and is not a current installer output (see the row above).§3 Step 5 uses .yml and states "that uppercase extension is an OCR artifact; the real files are lowercase .yml." (The extracted .md retains the book's .YAML because it's the verbatim source-of-truth.)
on: events / "the canonical workflow"Book's claude.yml excerpt shows only on: issue_comment: types: [created] (p. ~4), presented as the workflow.There is no single canonical/minimal workflow. The action's examples/claude.yml currently lists four events (issue_comment [created], pull_request_review_comment [created], issues [opened, assigned], pull_request_review [submitted]); the docs' inline "basic workflow" shows only two (issue_comment, pull_request_review_comment); and the examples/ directory has ~10 workflow files ([E1]/[E10]).Re-audited 2026-06-14. §2 now says "the example workflows listen on more than one event" and labels any single file representative, not canonical; §3 Step 5 introduces its YAML as "a representative claude.yml … verify against the live examples directory," not "the current minimal/shipped template." The shown block matches examples/claude.yml's four events (with correct per-event types).
Single unified action vs mode: inputsBook's @beta action used mode: "tag" / mode: "agent" inputs to switch behaviour.v1 is a single unified action that auto-detects whether it's responding to an @claude mention or running an automation; the old mode: inputs are removed ([E1]/[E9]).§2's "details the book simplifies" bullet states there's "now a single unified action that auto-detects... so the old mode: \"tag\" / mode: \"agent\" inputs are gone." §7's claude_args discussion reflects the v1 configuration model (prompt + claude_args), not mode:.
Model authentication pathsBook offers only OAuth-token-vs-API-key (p. ~3).The current action also supports Amazon Bedrock, Google Vertex AI, Microsoft Foundry, and Workload Identity Federation ([E3]).§3 Step 4 keeps the two as the primary choice (matching the chapter's narrative) and adds a parenthetical aside naming Bedrock/Vertex/Foundry/WIF "if your org needs them." Quiz q5's explanation mentions the extras but the question stays on the two primary paths.
Default no-auto-merge / human-in-the-loopBook narrative says Claude "automatically creat[es] a pull request" and "Claude initializes the integration by... automatically creating a pull request" (pp. ~4, 6) — reads as Claude opening the PR.Per the action's security doc ([E11]), the default is that Claude commits to a branch and provides a PR-creation link — it does NOT auto-open or merge the PR; a human creates/merges it (configurable).§2 step 6, §4, and §5 state Claude "pushes a branch and surfaces a PR link" and that "a human reviews and merges." The default-no-auto-merge safeguard is a recurring thread (preface, §2 figure, §4, common-pitfalls). Quiz q6's correct option includes "Claude also doesn't auto-merge by default." NB: the setup PR in §3 Step 5 (the one that adds the workflow files) is genuinely opened by the install flow — that's distinct from the per-issue task PRs, which follow the push-branch-+-link default.
/install-github-app invocationBook reaches the command by typing /git first, which "reveals the /install-github-app command" (p. ~1).Current builds expose /install-github-app as a standalone command; the "via /git" routing is unverified in current docs.§3 presents /install-github-app as a standalone command directly, with a one-line note: "The book reaches this via typing /git first; in current builds /install-github-app is a standalone command you can invoke directly."
SDK nameBook calls the SDK powering the integration the "Claude Code SDK" (p. ~1).The SDK was renamed the "Claude Agent SDK" ([E6]).§2 uses "Claude Agent SDK" and notes the rename inline: "the SDK was previously called the 'Claude Code SDK.'" The objective and figure caption use "Agent SDK."
Anthropic dogfooding linkBook cites https://github.com/anthropics/skills/actions (p. ~1) as a public example of Anthropic using Claude Code via GitHub Actions.That page currently shows GitHub Copilot review runs, not claude-code-action — it does not demonstrate the book's claim as of 2026-06-13.The lesson does not use the anthropics/skills/actions link. "Why this chapter matters" instead points to the anthropics/claude-code-action/examples directory ([E10]) and the "How Anthropic teams use Claude Code" post ([E8], the Product Design team's automated PR comments) as the real-world references. The "Further reading" list cites [E8], [E9], and [E10].
gh CLI as a prerequisiteBook walks through installing and authenticating the gh CLI as a required prerequisite before running /install-github-app (pp. ~1–2).Current docs ([E1]) do not list gh as a prerequisite for /install-github-app — the documented setup is just "open claude and run /install-github-app" (the only stated requirement is repo-admin access, plus being a direct Claude API user for the quickstart path).Added on 2026-06-14 re-audit. §3 Step 1 is retitled "(Optional) the GitHub CLI" and states gh is "useful for checking repo/auth state but not a required prerequisite"; the documented path is running /install-github-app in a repo you administer. Objective 2, the §3 mapping, and the practical-exercise Track A steps are aligned (Track A makes gh optional).
Subscription-token billing (June 15, 2026)Book pre-dates this; offers the subscription OAuth token for CI with no billing caveat (p. ~3).Per [E3] and [E5] (verbatim on both pages): "Starting June 15, 2026, Agent SDK and claude -p usage on subscription plans will draw from a new monthly Agent SDK credit, separate from your interactive usage limits." The GitHub Action runs Claude headlessly via the Agent SDK, so a subscription token in CI is in scope.Added on 2026-06-14 re-audit (the date is one day out — effective 2026-06-15). §3 Step 4 adds an "as of writing — verify the current terms" caveat at the claude setup-token bullet; the Further-Reading authentication bullet repeats it. Canonical wording is singular "a new monthly Agent SDK credit."

PDF page-number caveat

The Chapter 5 extraction lacked clean form-feed page boundaries, so the cleaned extracted-chapters/05-chapter-05.md uses approximate <!-- page N --> markers (8 of them, hand-placed at section transitions). All page references in this ledger (p. ~N) are therefore approximate and based on those reconstructed boundaries, not on printed book page numbers or reliable form-feed positions. The printed book may number these differently. Cross-check with the printed book if exact pagination is required; the section names ("Installing and configuring the Claude Code GitHub integration," "Using Claude Code to resolve GitHub issues," "Adding repository context with CLAUDE.md") are the more reliable locators.

Chapter 6: Claude Code Planning and Multi-agent Workflows

Source Ledger — Chapter 6: Claude Code Planning and Multi-agent Workflows

Primary source (the book)

  • Source PDF: source-pdfs/06-chapter-06.pdf (16 pages)
  • Extracted source: extracted-chapters/06-chapter-06.md (cleaned, with <!-- page N --> markers for all 16 pages). There is no usable .txt for this chapter — see the Extraction caveat at the end.
  • Extraction tool: none of the usual text extractors worked — the Chapter 6 PDF is image-only (each page is composed of rendered images; pdftotext -layout and pypdf both returned 0 characters). The chapter was extracted by rendering all 16 pages to PNG at 150 DPI with PyMuPDF (fitz) and transcribing them visually into extracted-chapters/06-chapter-06.md. The transcription preserves the book's original wording verbatim (including stale terminology and one page-break artifact in a numbered list).
  • Book's main sections (from the extract): "Claude Code planning mode" → "Characteristics of planning mode" → "Benefits of spec-driven development" → "Example: Iterating on the hook marketplace specification" → "Persisting the hook marketplace specification" (pp. 2–7); "Running Claude Code agents in parallel" → "Example: Parallel development in the HookHub project" → "Assigning independent tasks to agents" → "Executing tasks concurrently" → "Reviewing and committing changes" (pp. 8–14); "Summary" (p. 15).

Enrichment sources

The lesson silently incorporates material from the official Claude Code documentation and Anthropic's blog. Per project convention, no inline > Source: or > Enrichment — ... labels appear in the learner-facing lesson — the only in-lesson labelled callouts are the > Analogy — ... boxes. This source ledger is the single source of provenance.

  • [E1] Anthropic docs — Permission modes / plan mode — https://code.claude.com/docs/en/permission-modes
  • [E2] Anthropic docs — Claude Code best practices (explore-plan-code-commit) — https://code.claude.com/docs/en/best-practices
  • [E3] Anthropic docs — Git worktrees — https://code.claude.com/docs/en/worktrees
  • [E4] Anthropic docs — Subagents — https://code.claude.com/docs/en/sub-agents
  • [E5] Anthropic docs — Agent teams — https://code.claude.com/docs/en/agent-teams
  • [E6] Anthropic docs — Common workflows (plan mode) — https://code.claude.com/docs/en/common-workflows#how-to-use-plan-mode (the book's own cited pointer for plan mode)
  • [E7] Anthropic docs — Memory / CLAUDE.md — https://code.claude.com/docs/en/memory
  • [E8] Anthropic docs — Agents overview (parallel-work surfaces) — https://code.claude.com/docs/en/agents
  • [E9] Anthropic docs — Slash commands — https://code.claude.com/docs/en/commands
2026-06-14 accuracy re-audit. An independent audit flagged several over-/under-statements in the multi-agent, worktree, and spec-persistence material. All were verified against the current canonical docs ([E1]–[E9]) and corrected across the lesson, quiz, this ledger, and the training-output mirror. The Anthropic blog ("How Anthropic teams use Claude Code") was removed as an authority for Claude Code behavior — the parallel-sessions claim it supported is now grounded in the best-practices doc ([E2]). See the Drift / Corrections Applied table for the full list.

Unlike Chapter 5, the book is mostly current on this chapter's surface (verified against the canonical docs before authoring — see the Drift / Corrections Applied table). Enrichment is used to (a) complete the picture (the Shift+Tab and --permission-mode plan entry methods alongside the book's /plan; the explore-plan-code-commit framing), (b) name what the book describes only obliquely (Git worktrees — the book's "its own working directory on its own branch, with an independent copy of the codebase" is worktrees in all but name, deferred to "later in this book"), and (c) disambiguate the senses of "multi-agent" — the book leans on terminal instances vs subagents vs agent teams, and the lesson adds that current Claude Code has further parallel-work surfaces (Agent View / claude agents, dynamic workflows, /batch) so the three are taught as an on-ramp, not an exhaustive list.

Pedagogical enrichment by the training author

Not from the book and not from the docs — written for this training, inventoried here for separate audit. No inline labels in the lesson except the > Analogy — ... callouts.

  • Newcomer preface (## Before we start — planning, specs, and what "multi-agent" really means). Defines plan mode (read-only), specification / spec-driven development, independent vs dependent tasks, the senses of "multiple agents" (the book's three — terminal instances / subagents / agent teams — plus a pointer that current Claude Code has more: Agent View, dynamic workflows, /batch), and a short Git primer (branch, commit, status/diff/add/commit) for the parallel half. Grounded in [E1]–[E5], [E8], [E9]; the multi-agent disambiguation (and the explicit "this is bigger than three" note) is the chapter's central clarification.
  • Per-section analogies. Six > Analogy — ... callouts, one per numbered section: §1 measure twice, cut once; §2 the blueprint before the build; §3 two cooks, one kitchen; §4 laundry-and-dinner vs walls-and-paint; §5 two contractors, two rooms, one key rule; §6 shared bench, separate workshops, and an apprentice.
  • Whole-chapter analogy (## The whole chapter in one image — design it, split it, isolate it). A sustained house-renovation analogy threading all six sections (design before hammering → split by non-overlap → run independent crews in lanes → give each crew its own site).
  • Four SVG diagrams (the book's figures are screenshots and are not reproduced — we do not have rights, and they're image-only screenshots besides):
  • Figure 6.A — "explore → plan → code → commit": explore/plan read-only inside plan mode → committed spec.md (durable context) → approval gate → code/commit; the spec feeds code.
  • Figure 6.B — "Two instances, one shared branch": two terminals each scoped to a disjoint file merge cleanly; a warning that overlapping edits → conflict.
  • Figure 6.C — "Independent → parallel · Dependent → sequential": two independent lanes that merge vs a define-API→build-frontend chain.
  • Figure 6.D — (text table, not SVG) the three-mechanisms comparison (terminal instances / subagents / agent teams). Rendered as a Markdown table, not a diagram.
  • Each SVG figcaption explicitly notes it is pedagogical and not from the book.
  • Three-mechanisms comparison table (§6). Terminal instances (+ worktrees) vs subagents vs agent teams, by what-it-is / isolation / best-for. Pedagogical synthesis grounded in [E3]/[E4]/[E5].
  • Conceptual activity — "Spec it, then split it." Ten-minute individual exercise: write a five-line plan-mode spec for a small feature, decompose into 3–6 tasks, label each independent/dependent, and draw the parallel/sequential run plan (flagging hidden shared-file dependencies). Grounded in §2 and §4.
  • Practical exercise — "Plan it read-only, then build it with two agents at once." A ~35–45 min hands-on lab on a framework-free static "linkboard" sandbox (a HookHub stand-in: index.html + two independent stylesheets styles/hero.css and styles/cards.css), created at ~/cct-ch6-lab/ outside the training repo. Part 1 drives plan mode read-only (confirm git status clean while planning) and persists a spec to .claude/linkboard-spec.md; Part 2 runs two claude instances in parallel, each scoped "modify only … / do not modify …" to one stylesheet, then reviews with git status/git diff and commits once; Part 3 (stretch) upgrades to claude --worktree for true isolation and asks the learner to name a colliding task pair. The sandbox deliberately uses no npm/Node (the book's HookHub is Next.js) so every learner can run it.

Quiz items and learning objectives remain grounded in the book chapter and the labelled enrichment; none of the analogies, diagrams, the comparison table, the activity, or the exercise steps are themselves assessed.

Objective → Source Mapping

Learning ObjectiveSource Section (page)EnrichmentConfidenceNotes
Explain what plan mode is (read-only explore/design before edits), how to enter it (/plan, Shift+Tab cycle, --permission-mode plan), what it can/can't do, and how approval transitions to execution.Book "Claude Code planning mode" + "Characteristics of planning mode" + "The planning workflow" (pp. 2–3)[E1], [E6]HighBook teaches /plan only; the Shift+Tab cycle and --permission-mode plan flag are added from [E1]. Book's "cannot edit/create/delete, make Git commits, install packages, or perform execution-level actions" is preserved verbatim (incl. "install packages"). The approval-menu wording is intentionally generic per the soft-wording rule (the exact options move between releases).
Apply spec-driven development: produce a spec in plan mode, refine it, persist it to a committed Markdown file as durable context; place it in explore → plan → code → commit.Book "Benefits of spec-driven development" + "Example: Iterating on the hook marketplace specification" + "Persisting the hook marketplace specification" (pp. 3–7)[E2], [E7]HighThe explore-plan-code-commit four-phase framing and "self-contained spec" guidance are from [E2]; the book describes the same loop without naming the four phases. The .claude/ home for the spec is the book's ("such as a .claude directory").
Run multiple Claude Code instances in parallel on a shared codebase, and explain why the same-branch approach is the simplest and most fragile form.Book "Running Claude Code agents in parallel" + the closing Note (pp. 8, 14)[E2]HighBook is explicit on both the capability and the "inherently fragile … same branch with shared file access" framing. The "running several sessions in parallel for independent work" framing is grounded in [E2]'s documented menu of parallel approaches (worktrees / desktop app / web / agent teams) — re-audited 2026-06-14, replacing an earlier blog-sourced "many sessions in parallel" claim.
Distinguish independent vs dependent tasks and describe the engineer's shift to coordination/oversight.Book p. 9 ("Parallel execution is effective when tasks are independent …"; full-stack frontend/backend example; "the role of the engineer shifts …")n/aHighCaptured faithfully; the full-stack frontend-depends-on-backend-API example is the book's.
Execute a parallel workflow end to end on independent files with scoped "modify only" prompts, then review/commit with Git.Book "Example: Parallel development in the HookHub project" → "Assigning independent tasks" → "Running Multiple Claude Code Instances" → "Executing tasks concurrently" → "Reviewing and committing changes" (pp. 9–14)n/aHighThe git checkout/reset --hard/npm install/npm run dev baseline, the two scoped prompts (HookCard.tsx / Hero.tsx, "Modify only … Do not modify …"), and the git status/diff/add/commit review are all the book's.
Contrast the main "multiple-agent" mechanisms (terminal instances + worktrees / subagents / agent teams), recognize current Claude Code has further parallel-work surfaces, and explain why isolation answers the conflict risk.Book closing Note + Summary (pp. 14–15) — names subagents as the next chapter and "branch isolation … covered later in this book"[E3], [E4], [E5], [E8]High — synthesisThe book defers worktrees ("its own working directory on its own branch, with an independent copy of the codebase") and subagents to later chapters; the lesson names worktrees (claude --worktree) per [E3], distinguishes subagents per [E4] (noting they parallelize and can use isolation: worktree), adds agent teams per [E5] (experimental, off by default), and per [E8] flags the broader landscape (Agent View, dynamic workflows, /batch) so "three" isn't taught as exhaustive.

Lesson Section → Source Mapping

Lesson sectionSource locationEnrichmentConfidenceNotes
Preface — plan mode / spec / independent-vs-dependent / senses of "multi-agent" (+ "bigger than three" pointer) / Git primerBook pp. 2, 8–9 (concepts introduced)[E1]–[E5], [E8], [E9]HighPedagogical re-framing for newcomers. The multi-agent disambiguation is the lesson's; the book uses "multi-agent" loosely. Re-audited 2026-06-14: the preface now frames the book's three as an on-ramp and names the further surfaces (Agent View claude agents, dynamic workflows, /batch) per [E8]/[E9], and notes agent teams are experimental/off-by-default per [E5].
"Why this chapter matters" — structure-before-action; complexity → plan mode, throughput → parallelBook p. 1 (intro: "relying on ad hoc prompting increases the risk of unintended changes …")[E2]HighThe complexity framing is the book's intro. Re-audited 2026-06-14: the throughput framing is now grounded in [E2]'s documented menu of parallel approaches (worktrees / desktop app / web / agent teams), replacing an earlier blog-sourced "thought partner / many sessions in parallel" claim.
§1 — plan mode: read-only, three entry methods, can/can't list, approval transitions to executionBook pp. 2–3 ("Claude Code planning mode", "Characteristics of planning mode", "The planning workflow")[E1], [E6]HighEntry methods beyond /plan and the read-only-but-can-run-read-commands nuance from [E1]. Book's own Note (p. 1) points readers to [E6].
§1 — analogy: measure twice, cut oncen/a — pedagogicaln/an/aOriginal.
§2 — spec-driven development; HookHub spec drafted, refined (carousel removed, event types added), persisted to a committed .md; explore→plan→code→commitBook pp. 3–7 (the full HookHub spec example incl. the carousel→all-cards refinement and "export … to a Markdown file … .claude directory"; the book calls the committed spec "persistent project memory" — see extract p. 7)[E2], [E7]HighThe four-phase explore-plan-code-commit names and "self-contained spec" guidance are from [E2]. Carousel direction verified against the extract: the initial spec featured a carousel and a subset of event types; feedback removed the carousel (show all cards) and added event types. Re-audited 2026-06-14: the lesson reframes the book's "persistent project memory" as durable repo context and adds the precise nuance from [E7] that a file in .claude/ is not auto-loaded unless CLAUDE.md @-imports it (only CLAUDE.md/imports + auto-memory load automatically). See the Drift table.
§2 — Figure 6.A (explore→plan→code→commit, spec feeds code, approval gate)n/a — pedagogical diagram[E2]n/aOriginal SVG.
§2 — analogy: the blueprint before the buildn/a — pedagogicaln/an/aOriginal.
§3 — running multiple instances in parallel; same-branch shared-files model; "introductory example of multi-agent"; fragilityBook p. 8 + closing Note (p. 14)[E2]HighEverything here is the book's. Re-audited 2026-06-14: the "running several sessions in parallel for independent work" framing is now grounded in [E2]'s documented menu of parallel approaches, replacing an earlier blog-sourced "many sessions in parallel" detail.
§3 — Figure 6.B (two instances, one shared branch; clean only if files disjoint)n/a — pedagogical diagramn/an/aOriginal SVG. Visualises the book's Fig 6.4 argument (which we do not reproduce).
§3 — analogy: two cooks, one kitchenn/a — pedagogicaln/an/aOriginal.
§4 — independent vs dependent tasks; full-stack example; engineer shifts to oversightBook p. 9 — quoted closelyn/aHighFaithful to the book.
§4 — Figure 6.C (parallel lanes vs dependency chain)n/a — pedagogical diagramn/an/aOriginal SVG.
§4 — analogy: laundry-and-dinner vs walls-and-paintn/a — pedagogicaln/an/aOriginal.
§5 — HookHub walkthrough: baseline (git checkout/reset/npm), two independent tasks, two scoped terminals, concurrent execution, review/commitBook pp. 9–14 — quoted closely (commands and prompts preserved)n/aHighThe exact commands and the two "Modify only … Do not modify …" prompts are the book's.
§5 — analogy: two contractors, two rooms, one key rulen/a — pedagogicaln/an/aOriginal.
§6 — worktrees as the isolation fix (claude --worktree, with caveats); parallel-work-surfaces table; subagents next chapter; agent teams; broader landscapeBook closing Note + Summary (pp. 14–15) — defers isolation and subagents to later[E3], [E4], [E5], [E8]HighThe book describes worktrees without naming them and points forward; the lesson names them per [E3]. Re-audited 2026-06-14: §6 now carries the documented worktree caveats from [E3] (.claude/worktrees/<name> + branch worktree-<name>; branches from origin/HEAD unless worktree.baseRef: "head"; add .claude/worktrees/ to .gitignore; conditional cleanup, not unconditional auto-cleanup); the subagent row now says subagents parallelize work and can use isolation: worktree per [E3]/[E4] (dropping "context protection, not parallel speed"); agent teams are flagged experimental/off-by-default (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS) per [E5]; and the broader surfaces (Agent View, dynamic workflows, /batch) are named per [E8] so the table reads as a family, not an exhaustive "three."
§6 — Figure 6.D (three-mechanisms table)n/a — pedagogical[E3], [E4], [E5]n/aRendered as a Markdown table.
§6 — analogy: shared bench, separate workshops, and an apprenticen/a — pedagogicaln/an/aOriginal.
Whole-chapter analogy: design it, split it, isolate it (house renovation)n/a — pedagogical synthesisn/an/aOriginal.
Activity: Spec it, then split itn/a — pedagogical[E2]n/aOriginal. Grounded in §2/§4.
Practical exercise: Plan it read-only, then build it with two agents at once (linkboard sandbox + worktree stretch)Book pp. 2–14 recombined into a framework-free lab[E1], [E3]High — original sequencingPart 1 plan mode per [E1]; Part 3 worktrees per [E3]. Sandbox ~/cct-ch6-lab/ is outside the training repo and uses no npm/Node.

Unsupported / Pedagogical-Only Claims

Statements in the learner-facing lesson that are not from the book and not directly from the labelled enrichment, listed for isolated audit.

ItemJustification
Measure-twice-cut-once analogy (§1)Pedagogical analogy. No external claim.
Blueprint-before-the-build analogy (§2)Pedagogical analogy. Restates the spec-as-durable-artifact idea.
Two-cooks-one-kitchen analogy (§3)Pedagogical analogy. Restates the same-branch-fragility point.
Laundry-and-dinner vs walls-and-paint analogy (§4)Pedagogical analogy. Restates independent-vs-dependent.
Two-contractors-two-rooms analogy (§5)Pedagogical analogy. Restates the scoped-prompt walkthrough.
Shared-bench/separate-workshops/apprentice analogy (§6)Pedagogical analogy. Restates worktrees-vs-subagents.
Whole-chapter house-renovation analogyPedagogical synthesis. No new claims.
Figures 6.A–6.C (SVGs)Original SVGs. Visually restate the explore-plan-code-commit pipeline, the shared-branch model, and the parallel-vs-sequential test.
Three-mechanisms comparison table (§6)Pedagogical synthesis grounded in [E3]/[E4]/[E5].
"Structure before action" thesis (Why-this-chapter + closing)Pedagogical framing synthesising the book's two halves; not a single book sentence.
Conceptual activity (Spec it, then split it)Original exercise; grounded in §2/§4 and [E2].
Practical exercise (linkboard sandbox), all partsOriginal sequencing; every step grounded in the book or [E1]/[E3]. The index.html/hero.css/cards.css sandbox files are authored for this training; sandbox at ~/cct-ch6-lab/ is outside the training repo.

Quiz Item → Source Mapping

Quiz IDItemSource locationEnrichmentConfidence
q1What plan mode is (read-only explore/design), its capability boundaries (can read/analyze/MCP/search; can't edit/create/delete/commit/install), and the three entry methods (/plan, Shift+Tab, --permission-mode plan).Book pp. 2–3[E1]High — entry methods beyond /plan from [E1]; the can/can't list is the book's (incl. "install packages").
q2Why export and commit the spec (durable repo context — versioned, shared/reviewed, a later session pointed at it) and the primary benefit of spec-driven dev (separation of planning and execution → lower risk, higher reliability).Book pp. 3–7[E2], [E7]High — re-audited 2026-06-14: option/explanation reworded from "persistent project memory" to "durable repo context," with the .claude/-isn't-auto-loaded-unless-@-imported nuance from [E7].
q3How parallel runs are set up (several full instances, one per terminal, same project) and the book's framing of the same-branch demo as the simplest, inherently fragile form.Book p. 8 + closing Note (p. 14)[E2]High — re-audited 2026-06-14: enrichment re-pointed from the blog to [E2].
q4Independent vs dependent tasks (independent → parallel; dependent like frontend-needs-backend-API → sequential) and the engineer's shift to coordination/oversight.Book p. 9 — quotedn/aHigh
q5The HookHub scoping mechanism ("Modify only … Do not modify …" per file, separate files so no overlap) and the review-then-commit-once Git flow (status/diff/add/commit).Book pp. 12–14 — quotedn/aHigh
q6Synthesis: distinguishing terminal instances vs subagents vs agent teams (and noting these aren't the whole list), with subagents shown as parallelizing + worktree-capable and agent teams as experimental/off-by-default, plus Git worktrees (claude --worktree) as the documented fix for same-branch fragility.Book closing Note + Summary (pp. 14–15)[E3], [E4], [E5], [E8]High — the one enrichment-grounded synthesis question. Re-audited 2026-06-14: the prompt no longer asserts "three different things" as exhaustive; option b/explanation now say subagents parallelize and can use isolation: worktree, agent teams are experimental (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS), and current Claude Code has further surfaces (Agent View, dynamic workflows, /batch) per [E8].

Drift / Corrections Applied

The book is largely current on this chapter's surface (verified against [E1]–[E9]). The items below are the places the lesson completes, renames, or softens the book — none are book errors of the Chapter-5 magnitude. The 2026-06-14 re-audit added the worktree-caveats, subagent-capabilities, agent-teams-gating, spec-memory-framing, and blog-removed rows below.

ItemBook positionCurrent positionLesson treatment
Plan mode entry methodsBook teaches /plan as the way to enter planning mode (p. 4)./plan is current and correct ([E1]). Plan mode can also be entered by cycling permission modes with Shift+Tab (default → accept-edits → plan) or by starting a session with claude --permission-mode plan ([E1]).§1 presents /plan (the book's) plus the Shift+Tab cycle and --permission-mode plan flag, citing [E1]. No correction — an addition. q1's correct option lists all three.
Plan-mode approval optionsBook: "Upon approval, Claude Code exits planning mode and proceeds with implementation" (p. 3).Correct ([E1]). On approval, Claude offers a choice of how to proceed (e.g., auto-accept edits, review each edit, or keep refining) — the exact menu wording moves between releases.§1 states approval exits plan mode into an editing mode and lets you choose your oversight level, without hardcoding the menu labels (soft-wording rule).
Git worktrees — exact behaviorBook describes the professional approach only obliquely — each agent "operates in its own working directory on its own branch, with an independent copy of the codebase" — and explicitly defers "branch isolation and structured merge workflows … covered later in this book" (pp. 14–15).Per [E3]: claude --worktree <name> creates the worktree at .claude/worktrees/<name>/ on a new branch worktree-<name>; worktrees branch from the remote default (origin/HEAD) unless worktree.baseRef is set to "head" (so local unpushed commits aren't present by default); .claude/worktrees/ should be added to .gitignore; and cleanup is conditional — a clean, unnamed session is auto-removed on exit, but named sessions prompt, sessions with changes/commits prompt, and non-interactive (-p) runs are not auto-removed (git worktree remove manually).Re-audited 2026-06-14. §6 and the practical-exercise Part 3 now carry the path/branch defaults, the origin/HEAD vs worktree.baseRef: "head" base-branch caveat (with the explicit warning that a learner's local committed spec won't appear in a remote-based worktree), the .gitignore note, and the conditional-cleanup rules. The earlier unconditional "cleans the worktree up automatically" / "automatic cleanup" wording was removed.
"Multi-agent" landscape (not just three)Book uses "multi-agent"/"agents"/"instances" loosely; mentions sub-agents as the next chapter and once notes the spec "ensures consistent guidance when working with subagents" (pp. 7, 8, 15).Current Claude Code documents several parallel-work surfaces ([E8]): multiple terminal instances (this chapter), subagents ([E4]), agent teams ([E5]), Agent View (claude agents, a background-session monitor), dynamic workflows (a script running many subagents with cross-checking), and /batch ([E9], a skill splitting one change into 5–30 worktree-isolated subagent PRs).Re-audited 2026-06-14. The preface and §6 now teach the book's three as an on-ramp and explicitly name the further surfaces, and q6 no longer asserts "three different things" as an exhaustive current fact.
Subagents — capabilities(Book defers subagents to the next chapter; the draft lesson described them as "context protection, not parallel speed.")Per [E4]/[E3]: subagents parallelize work (the agent-teams doc: "Both agent teams and subagents let you parallelize work, but they operate differently") and protect context, and they can run in isolated worktrees — isolation: worktree in custom-subagent frontmatter, or asking Claude to "use worktrees for your agents."Added 2026-06-14. The preface, §6 table, q6, the common-pitfalls note, and the §6 analogy were reworded to drop "context protection, not parallel speed" as an absolute and to say subagents both protect context and parallelize (and can use worktree isolation).
Agent teams — experimental & gated(Book doesn't cover agent teams; the draft lesson introduced them without a status caveat.)Per [E5]: "Agent teams are experimental and disabled by default." Enable with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS (set to "1") in settings.json or the environment.Added 2026-06-14. Every place agent teams are introduced or contrasted (preface, §6 table, q6) now carries the experimental/off-by-default caveat and the exact env var.
Spec persistence / memory framingBook p. 7 literally calls the committed spec "persistent project memory" (preserved verbatim in the extract).Per [E7]: only CLAUDE.md (and its @-imports) and Claude's auto-memory (~/.claude/projects/<project>/memory/) load automatically. An arbitrary .claude/<file>.md is not auto-loaded unless CLAUDE.md @-imports it; otherwise it's a file you point Claude at. Best-practices ([E2]) frames it as a self-contained spec you reference in a fresh session.Re-audited 2026-06-14. The lesson and q2 reframe the book's "persistent project memory" as durable repo context / a committed spec a later session can be pointed at, and add the @-import nuance. The book's exact phrase is retained only as labelled book-source context in the extract and this ledger.
Blog removed as authority(Draft lesson cited the "How Anthropic teams use Claude Code" blog for the factual claim that the creator/teams "routinely run many sessions in parallel," plus the "thought partner, not code generator" framing.)The same parallel-sessions point is documented in [E2] ("Run multiple Claude sessions" — a menu of worktrees / desktop app / web / agent teams).Re-audited 2026-06-14. The blog was removed from this chapter's enrichment list, the lesson §3 / "why this chapter matters" / Further Reading, and the training-output mirror; the claim is now grounded in [E2]. (Per the audit, the blog is not used as authority for Claude Code behavior in this pass.)
Numbered-list page-break artifactThe extract's "planning workflow follows a structured sequence" list starts at "3." (steps 1–2 were cut at the page-3 break in the image-only source).n/a — extraction artifact, not a book error.The lesson does not reproduce the broken list; it states the workflow as prose (research/design read-only → plan presented for review → on approval, exit to implementation). Noted here and in the extract so a reviewer isn't confused by the 3./4. start in extracted-chapters/06-chapter-06.md.
HookHub is a Next.js projectBook: HookHub is "a new Next.js project" with .tsx components and npm install/npm run dev (pp. 4, 10, 12).Accurate to the book.§5 preserves the book's Next.js/.tsx/npm specifics. The practical exercise, for portability, uses a framework-free static sandbox instead (noted as an intentional substitution so no learner needs Node).

Extraction caveat (image-only PDF)

source-pdfs/06-chapter-06.pdf is an image-only PDF — every page is a set of rendered images with no text layer (confirmed: pdftotext -layout and pypdf both returned 0 characters; pages carry 16–21 embedded images each). Standard extraction was therefore impossible. The source-of-truth extracted-chapters/06-chapter-06.md was produced by rendering each page to PNG at 150 DPI (PyMuPDF) and transcribing the images visually. Consequences a reviewer should know:

  • Page markers are reliable (the renderer gave clean per-page boundaries), but printed book page numbers are unknown — <!-- page N --> is the PDF page index, not the book's printed page.
  • The book's figures are screenshots (terminal/browser captures embedded as images). They are not transcribed pixel-for-pixel and not reproduced in the lesson (we have no rights, and they're bitmaps). Figure captions are preserved in the extract, marked "(screenshot, not transcribed)". The one figure with narrative text baked in (Fig 6.4, the shared-codebase/merge-conflict diagram) had several low-confidence labels marked [unclear] in the extract — none of those uncertain labels are relied on by the lesson (the lesson's §3 claims rest on the clean body prose, not the diagram text).
  • Re-transcription, not OCR. No OCR engine (tesseract) or PDF rasterizer (pdftoppm/ghostscript) was available locally; PyMuPDF was installed specifically to render the pages. If exact wording matters for a citation, cross-check against the printed book.
Chapter 7: Working with Claude Code Subagents

Source Ledger — Chapter 7: Working with Claude Code Subagents

Primary source (the book)

  • Source PDF: source-pdfs/07-chapter-07.pdf (57 pages)
  • Extracted source: extracted-chapters/07-chapter-07.md (visual transcription, with <!-- page N --> markers for all 57 pages). There is no usable .txt for this chapter — see the Extraction caveat at the end.
  • Extraction tool: none of the usual text extractors worked — the Chapter 7 PDF is image-only (each page is composed of rendered images; pdftotext -layout and pypdf both returned 0 characters). The chapter was extracted by rendering all 57 pages to PNG at 150 DPI with PyMuPDF (fitz) into work/07-chapter-07-pages/ and transcribing them visually into extracted-chapters/07-chapter-07.md. The transcription preserves the book's original wording verbatim — including stale terminology (the "Task tool" name) and the creator's misspelled handle ("IndieDevDan" / "IndieDev.com").
  • Book's main sections (from the extract): "Introduction to Claude Code subagents" (pp. 2–7); "Configuring the first subagent" via /agents — describe / generate-with-Claude / manual, tool selection, model/visual settings, reviewing the generated code-comedy-carl.md (pp. 8–13); "Testing our subagent" — Fibonacci file, funny review @main.py, spawning two sequential instances (pp. 13–16); "Context flow while using subagents" + "Context windows in action" — the one-prompt-down / one-summary-back model and the 200K-token worked example (pp. 16–20); "Example: Creating a Mermaid diagram subagent" — tool pollution, the two levers (description vs system-prompt body), the untrusted-definition security warning, refining output to return only the diagram code (pp. 20–35); "Scaling with concurrent subagents" — the Infinite Agentic Loop repo, HookHub setup, /infinite, six parallel Hero variations, human selection (pp. 35–48); "Infinite prompt" — the high-order/meta prompt under the hood, four phases, the Agent ("task") tool, agent assignment protocol (pp. 49–56); "Summary" (pp. 56–57).

Enrichment sources

The lesson silently incorporates material from the official Claude Code documentation, Anthropic's engineering blog, the Anthropic cookbook, and one community pattern repository. Per project convention, no inline > Source: or > Enrichment — ... labels appear in the learner-facing lesson — the only in-lesson labelled callouts are the > Analogy — ... boxes. This source ledger is the single source of provenance.

  • [E1] Anthropic docs — Subagents — https://code.claude.com/docs/en/sub-agents
  • [E2] Anthropic docs — Run agents in parallel / agents overview — https://code.claude.com/docs/en/agents
  • [E3] Anthropic docs — Agent teams — https://code.claude.com/docs/en/agent-teams
  • [E4] Anthropic docs — Slash commands — https://code.claude.com/docs/en/commands
  • [E5] Anthropic docs — Worktrees — https://code.claude.com/docs/en/worktrees
  • [E6] Anthropic engineering — How we built our multi-agent research system — https://www.anthropic.com/engineering/multi-agent-research-system
  • [E7] Anthropic engineering — Building effective agents — https://www.anthropic.com/engineering/building-effective-agents
  • [E8] Anthropic engineering — Effective context engineering for AI agents — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
  • [E9] Anthropic cookbook — Orchestrator-workers / using sub-agents — https://platform.claude.com/cookbook/patterns-agents-orchestrator-workers (and https://platform.claude.com/cookbook/multimodal-using-sub-agents)
  • [E10] Community pattern — Infinite Agentic Loop by IndyDevDan / disler — https://github.com/disler/infinite-agentic-loop (MIT; creator's site https://agenticengineer.com, channel https://www.youtube.com/@indydevdan)

The book is largely current on this chapter's surface (subagents had not drifted far between the book's writing and this build — verified against the canonical docs before authoring; see the Drift / Corrections Applied table). Enrichment is used to (a) complete the picture (the frontmatter schema beyond what the book lists, the built-in Explore/Plan agents, the three invocation methods, the broader scope hierarchy); (b) quantify and ground the context-isolation argument (the ~1,000–2,000-token condensed-summary figure and the "attention budget" framing from [E8]; the ~4×/~15× token multipliers and the orchestrator-worker architecture from [E6]; the orchestrator-workers pattern name from [E7]); and (c) correct two genuine book errors (the creator's name/handle and the framing of the Infinite Agentic Loop as merely "the implementation" rather than a community pattern).

Pedagogical enrichment by the training author

Not from the book and not from the docs — written for this training, inventoried here for separate audit. No inline labels in the lesson except the > Analogy — ... callouts.

  • Newcomer preface (## Before we start — agents, subagents, context windows, and "meta" prompts). Defines the main agent, a subagent (own system prompt / own isolated context window / selective tool access), a context window and why quality degrades before the ceiling (the attention-budget idea), system prompt vs user prompt, concurrent vs sequential, a "meta"/high-order prompt by analogy to higher-order functions, and where this sits relative to Chapter 6's three senses of "multiple agents." Grounded in [E1], [E8]; the higher-order-functions analogy and the Chapter-6 bridge are the chapter's framing devices.
  • Per-section analogies. Seven > Analogy — ... callouts, one per numbered section: §1 the specialist with a sealed brief; §2 filling out the job requisition; §3 the cautious dispatcher; §4 the assistant who hands you a one-page memo; §5 the recipe card and the cook's training; §6 six architects, one brief; §7 the manager who writes the tickets, not the code.
  • Whole-chapter analogy (## The whole chapter in one image — delegate, isolate, then multiply). A sustained consulting-partner analogy threading all seven sections (take the meeting / delegate the digging → staff each job deliberately → tune on two dials → run a competition for the biggest decisions).
  • Three SVG diagrams (the book's figures are screenshots and are not reproduced — we do not have rights, and they're image-only screenshots besides):
  • Figure 7.A — main↔subagent context flow: one prompt down, one condensed summary (~1–2k tokens) back, the subagent's heavy internal tokens never added to the lean main thread.
  • Figure 7.B — the two levers: the description (read by Claude to decide when to delegate and to write the task prompt it sends the subagent) vs the system-prompt body (sent only to the subagent → controls internal logic and output format).
  • Figure 7.C — the Infinite Agentic Loop fan-out: one spec + count → main agent as orchestrator → a wave of six parallel subagents (via the Agent tool) → many variations → human review and selection; infinite mode plans further waves until context runs out.
  • Each SVG figcaption explicitly notes it is "Pedagogical diagram by this training, not from the book."
  • Conceptual activity — "Design a subagent on paper." Ten-minute individual exercise: pick a recurring side-task, write the frontmatter (name + trigger-bearing description), apply least privilege to tools (and name what's withheld and why), write one lever-2 body instruction that controls output format, and decide the parallelism phrasing. Grounded in §1/§3/§5.
  • Practical exercise — "Build, shape, and parallelize a subagent." A ~35–45 min hands-on lab on a framework-free, stdlib-only Python sandbox (three small files with planted defects — prices.py float-drift, auth.py non-constant-time comparison, slugify.py missing punctuation strip), created at ~/cct-ch7-lab/ outside the training repo. Part 1 creates a least-privilege reviewer with /agents (project scope, generate-with-Claude, read-only tools); Part 2 invokes it on one file and watches context isolation (/context, plus the /agents Running tab and Ctrl+O transcript viewer); Part 3 pulls both levers (edit the body for an output-format change requiring a restart; tighten the description for an emphasis change); Part 4 contrasts the sequential phrasing against an explicit "in parallel / a separate agent for each" phrasing to force concurrency. The sandbox deliberately uses no npm/Node (the book's HookHub is Next.js) so every learner can run it.

Quiz items and learning objectives remain grounded in the book chapter and the labelled enrichment; none of the analogies, diagrams, the activity, or the exercise steps are themselves assessed.

Objective → Source Mapping

Learning ObjectiveSource Section (page)EnrichmentConfidenceNotes
Explain what a subagent is — own system prompt, own isolated context window, selective tool access — and how it differs from the main agent (doesn't see the conversation history; returns one condensed summary).Book "Introduction to Claude Code subagents" (pp. 2–3) + "Context flow while using subagents" (pp. 16–18)[E1]HighThe three defining properties and the isolation/condensed-summary framing are the book's; [E1]'s "does not see your conversation history, the skills you've already invoked, or the files Claude has already read" sharpens the wording.
Create a subagent with /agents (guided / generate-with-Claude / manual) and read or author its Markdown definition: required name/description, the tools allowlist (omit → inherit all), model (incl. inherit), and project (​.claude/agents/) vs user (~/.claude/agents/) scope.Book "Configuring the first subagent" → "Reviewing the generated agent configuration" (pp. 8–13) + frontmatter/schema discussion (pp. 6–7)[E1]HighGenerate-with-Claude vs manual, the code-comedy-carl walkthrough, the two file directories, and "if left empty… granted access to all available tools" are the book's. model defaulting to inherit and the broader 5-level precedence are completed from [E1] (see Drift).
Invoke a subagent several ways — automatic delegation (description-driven), naming it in natural language, @-mention, and session-wide (claude --agent <name> / the agent setting; --agents JSON for session-only definitions) — and explain why instances run sequentially unless independence is explicit.Book "Running a code review subagent" + the two-instances note (pp. 14–15)[E1]HighThe book demonstrates the natural-language path and is explicit on sequential-by-default and the "review these files in parallel" / "separate agents for each file" influence. Automatic delegation, @-mention, and the session-wide --agent/agent/--agents methods are completed from [E1]; the book's "can also be invoked through a slash command" is softened, and the list is framed as a scale rather than a fixed count (see Drift).
Explain why subagents keep the main context lean (fresh isolated window from Claude's delegation message; heavy work stays out of the main thread; one condensed summary back) and connect it to finite context, context pollution, and the attention budget.Book "Context flow…" + "Context windows in action" (pp. 16–20)[E8], [E1]HighThe book's worked 200K-token growth example and the ~100K-internal → ~25K-summary illustration are preserved (size softened — see Drift). [E8] supplies the ~1,000–2,000-token condensed-summary figure and the "attention budget" / "finite resource with diminishing marginal returns" framing. [E1] "what loads at startup" corrects the book's "only context is the generated prompt": a non-fork subagent also loads its own system prompt+env, CLAUDE.md/memory, git status, and preloaded skills (Explore/Plan skip CLAUDE.md+git; forks inherit the parent) — see Drift.
Shape a subagent through its two levers — the description (when it fires + the task prompt Claude writes) and the system-prompt body (internal logic) — apply least privilege to tools (avoid tool pollution), and recognize the untrusted-definition security risk.Book "Example: Creating a Mermaid diagram subagent" → refining description → tool-pollution → security Pro Tip → refining output (pp. 20–35)[E1]HighBoth levers, tool pollution, and the untrusted-definition concern are the book's, demonstrated on the Mermaid agent. The book's "the description is appended to Claude Code's main agent system prompt" framing is reframed to current docs (Claude uses the description to decide when to delegate and composes the task prompt), and the warning is broadened to an untrusted definition's influence over routing/prompting/tools/permission mode/hooks/MCP/memory (see Drift). The Skills allowed-tools contrast is added from [E1] / the locked-in CLAUDE.md drift note.
Describe how concurrent subagents scale exploration via the Infinite Agentic Loop — one high-order ("meta") prompt fanning out to parallel subagents via the Agent tool to generate many variations for human selection — and judge when it's worth the token cost.Book "Scaling with concurrent subagents" + "Infinite prompt" (pp. 35–56)[E6], [E7], [E9], [E10]High — synthesisThe /infinite walkthrough, six Hero variations, "scale via compute," the four phases, and the high-order/meta-prompt framing are the book's. [E7] names the orchestrator-workers pattern; [E6] supplies the ~4×/~15× token multipliers and the cost-justification framing; [E10] is the canonical repo; [E9] is the runnable cookbook analogue.

Lesson Section → Source Mapping

Lesson sectionSource locationEnrichmentConfidenceNotes
Preface — agents/subagents/context windows/"meta" prompts; bridge from Chapter 6's three senses of "multiple agents"Book pp. 2–3, 16–19 (concepts introduced)[E1], [E8]HighPedagogical re-framing for newcomers. The higher-order-functions analogy and the explicit "this is that next chapter" bridge to Chapter 6 are the lesson's.
"Why this chapter matters" — context as the bottleneck; isolation buys both a lean main thread and parallelismBook intro (p. 1) + pp. 18–19[E8]HighThe "finite resource with diminishing marginal returns" quote is from [E8]; the context-pollution motivation is the book's.
§1 — what a subagent is; the defining file; required name/description; tools allowlist; model incl. inherit; scope directories; broader schemaBook pp. 2–7 (incl. Fig 7.1 file structure and the page-6 schema list)[E1]HighThe clean code-reviewer example is authored for the lesson (the book's equivalent example on pp. 3–5 is a sprawling project-specific reviewer); fields and behaviour match the book + [E1]. Schema-beyond-the-book (disallowedTools, permissionMode, mcpServers, isolation: worktree, etc.) and the built-in Explore/Plan agents come from [E1] (see Drift).
§1 — analogy: the specialist with a sealed briefn/a — pedagogicaln/an/aOriginal.
§2 — configuring with /agents; generate-with-Claude; the funny-reviewer description; tool selection (read-only); model selection (Sonnet); the saved code-comedy-carl.md; immediate effect; the "use Claude to improve the prompt" trickBook pp. 8–13 — quoted closely[E1]HighThe walkthrough, the funny-review trigger prompt, the code-comedy-carl frontmatter, and the Pro Tip are the book's. The "created via /agents takes effect immediately; on-disk file edits need a restart" distinction is completed from [E1] / current behaviour.
§2 — analogy: filling out the job requisitionn/a — pedagogicaln/an/aOriginal.
§3 — invocation methods (automatic delegation / natural-language naming / @-mention / session-wide --agent+agent setting / --agents JSON); sequential-by-default; phrasing for parallelism; watching subagents (/agents Running tab + Ctrl+O transcript viewer)Book pp. 14–15 — quoted closely[E1], [E2]HighSequential-by-default, the two-instances demo, and the "in parallel" / "separate agents for each" influence are the book's. The invocation methods are completed from [E1] (and framed as a scale, not a fixed count); the book's "can also be invoked through a slash command" is softened (see Drift). Ctrl+R/Cmd+R correction: an earlier draft said Ctrl+R/Cmd+R "expands the agent view to watch subagent activity" — that is wrong. Per [E1]/[E2]/interactive-mode docs, in-session Ctrl+R is reverse-history-search; Ctrl+O toggles the transcript viewer (detailed tool usage); the /agents Running tab lists live subagents; and claude agents (Agent View) is separate, where Ctrl+R renames a background session (see Drift).
§3 — analogy: the cautious dispatchern/a — pedagogicaln/an/aOriginal.
§4 — context flow; Claude writes a delegation message; "fresh ≠ empty" — what loads at startup (own system prompt+env, CLAUDE.md/memory, git status, preloaded skills; Explore/Plan skip CLAUDE.md+git; forks inherit the parent); one condensed summary back; finite window; context pollution; attention budgetBook pp. 16–20 (Figs 7.8–7.10, the 200K growth example)[E8], [E1]HighThe book's input/output model and the worked token-growth picture are preserved (size softened — see Drift). The ~1,000–2,000-token summary figure and the "attention budget" / recall-degrades-with-length framing are from [E8]. The book's "the only context the subagent receives is the generated prompt" is corrected from [E1]'s "what loads at startup" (system prompt+env, CLAUDE.md/memory, git status, preloaded skills; Explore/Plan exceptions; fork exception) — see Drift. The five docs-named benefits (preserve context / enforce constraints / reuse configs / specialize / control costs) are from [E1].
§4 — Figure 7.A (one prompt down, one summary back, lean main thread)n/a — pedagogical diagram[E8]n/aOriginal SVG.
§4 — analogy: the assistant who hands you a one-page memon/a — pedagogicaln/an/aOriginal.
§5 — two levers; the description is read by Claude to decide when to delegate and to compose the task prompt; <example> blocks; body controls internal logic/output format; tool pollution; untrusted-definition security warningBook pp. 20–35 (the Mermaid agent: tool pollution p. 22, description-as-prompt-shaper pp. 24–27, security Pro Tip p. 27, body fix for "respond with only the diagram" pp. 30–32)[E1]HighThe two-levers framing and the Mermaid demonstration are the book's. The book's claim that the description "is appended to Claude Code's main agent system prompt" (extract pp. 24, 27) is reframed to [E1]'s documented behavior — Claude uses the description to decide when to delegate and writes the subagent's task prompt — and the security warning is reframed from a "main-system-prompt hijack" to "an untrusted definition can influence routing, prompting, tools, permission mode, hooks, MCP, memory, or instructions" (see Drift). The contrast with a Skill's allowed-tools (a pre-approval grant, the opposite of a subagent's tools allowlist) is added per [E1] and the locked-in CLAUDE.md drift note.
§5 — Figure 7.B (description steers the main agent · body steers the subagent)n/a — pedagogical diagramn/an/aOriginal SVG.
§5 — analogy: the recipe card and the cook's trainingn/a — pedagogicaln/an/aOriginal.
§6 — Infinite Agentic Loop as a community pattern; /infinite <spec> <dir> <count>; six parallel Hero variations; human selection; "scale via compute"; the cost counterweightBook pp. 35–48 (the HookHub /infinite walkthrough; the six-variation list; "the number of tokens we are willing to spend…"; the cost Note p. 36)[E6], [E7], [E10]HighThe walkthrough and the six named variations (minimal/centered/waveform/particles/terminal/gradient-mesh) are the book's. [E10] is the canonical repo with the corrected attribution; [E6] supplies the ~4×/~15× multipliers and "value high enough to pay for the increased performance" / "fewer truly parallelizable tasks than research" cautions; [E7] supplies the orchestrator-workers name. The community-vs-official-feature framing corrects the book (see Drift).
§6 — Figure 7.C (the fan-out: one spec → wave of subagents → variations → human picks)n/a — pedagogical diagram[E6], [E7]n/aOriginal SVG.
§6 — analogy: six architects, one briefn/a — pedagogicaln/an/aOriginal.
§7 — the infinite prompt as a high-order/meta prompt; "Think deeply"; $ARGUMENTS LLM-parsed; four phases; the Agent tool (formerly Task); assignment packet; divergent-generation-not-tournament; orchestrator-workersBook pp. 49–56 (the infinite.md walkthrough, the four phases, "task tool," the assignment protocol, "kudos to IndieDev.com")[E7], [E10]HighThe four phases, $ARGUMENTS-parsed-by-the-LLM, and the assignment packet are the book's. The "Agent tool (formerly Task)" rename is completed from current Claude Code (see Drift). The "divergent generation, not an automatic tournament" clarification and the orchestrator-workers mapping ([E7]) are the lesson's precision over the book's looser framing.
§7 — analogy: the manager who writes the tickets, not the coden/a — pedagogicaln/an/aOriginal.
Whole-chapter analogy: delegate, isolate, then multiply (consulting partner)n/a — pedagogical synthesisn/an/aOriginal.
Activity: Design a subagent on papern/a — pedagogical[E1]n/aOriginal. Grounded in §1/§3/§5.
Practical exercise: Build, shape, and parallelize a subagent (stdlib Python sandbox)Book pp. 8–35 recombined into a framework-free lab[E1]High — original sequencingEvery step grounded in the book's /agents + two-levers + parallelism material. Sandbox ~/cct-ch7-lab/ is outside the training repo and uses no npm/Node.

Unsupported / Pedagogical-Only Claims

Statements in the learner-facing lesson that are not from the book and not directly from the labelled enrichment, listed for isolated audit.

ItemJustification
Specialist-with-a-sealed-brief analogy (§1)Pedagogical analogy. No external claim.
Job-requisition analogy (§2)Pedagogical analogy. Restates the /agents creation flow.
Cautious-dispatcher analogy (§3)Pedagogical analogy. Restates sequential-by-default.
One-page-memo analogy (§4)Pedagogical analogy. Restates context isolation.
Recipe-card / cook's-training analogy (§5)Pedagogical analogy. Restates the two levers + the untrusted-source caution.
Six-architects-one-brief analogy (§6)Pedagogical analogy. Restates the fan-out-and-select cost trade-off.
Manager-who-writes-the-tickets analogy (§7)Pedagogical analogy. Restates the meta-prompt idea.
Whole-chapter consulting-partner analogyPedagogical synthesis. No new claims.
Figures 7.A–7.C (SVGs)Original SVGs. Visually restate context flow, the two levers, and the Infinite Agentic Loop fan-out.
Higher-order-functions framing of "meta"/high-order prompts (preface, §7)Pedagogical framing; the book itself draws the same functional-programming analogy ("high-order functions… functions receive functions"). Restated for newcomers.
The clean code-reviewer frontmatter example (§1)Authored for the lesson as a tidy, current illustration in place of the book's sprawling project-specific reviewer (extract pp. 3–5). Field semantics match the book + [E1].
"Divergent generation, not an automatic tournament" (§7)Lesson clarification: the book never claims an automatic scoring/selection step; the lesson makes explicit that selection is human. Grounded in the book's own "render them, compare, choose the best one" flow.
Conceptual activity (Design a subagent on paper)Original exercise; grounded in §1/§3/§5 and [E1].
Practical exercise (stdlib Python sandbox), all partsOriginal sequencing; every step grounded in the book or [E1]. The three sandbox files with planted defects are authored for this training; sandbox at ~/cct-ch7-lab/ is outside the training repo.

Quiz Item → Source Mapping

Quiz IDAnswerItemSource locationEnrichmentConfidence
q1aWhat a subagent is and what makes it different from the main agent (own system prompt, own isolated context window, selective tool access; starts fresh from Claude's delegation message — no prior history/skills/files; returns one condensed summary).Book pp. 2–3, 16–18[E1]High — the three defining properties and the isolation/summary behaviour are the book's; the "starts fresh from a delegation message" wording is tightened to [E1] (replacing "only the prompt it's given").
q2cHow a subagent is defined (Markdown + YAML frontmatter; body = system prompt; only name/description required) and what tools (allowlist: omit → inherit all; list → restricted, unlike a Skill's allowed-tools) and file location (project .claude/agents/ vs user ~/.claude/agents/) control.Book pp. 5–7, 11–12[E1]High — the allowlist semantics are the book's; the Skills allowed-tools contrast and model defaulting to inherit from [E1].
q3bHow Claude decides whether subagent instances run concurrently (it does not assume independence → sequential when unsure) and how phrasing ("review these files in parallel" / "a separate review agent for each file") influences it.Book pp. 14–15 — quoted[E1]High — entirely the book's; ties back to Chapter 6's independent-vs-dependent judgment.
q4dThe two levers — description (Claude reads it to decide when to delegate and to write the task prompt) and the system-prompt body (internal logic / output format) — plus the untrusted-definition security risk (a definition controls tools, permission mode, hooks, MCP, memory, and routing/prompting).Book pp. 24–27, 30–32[E1]High — the two-levers framing and the security concern are the book's (demonstrated on the Mermaid agent); the option/explanation reframe the book's "description appended to the main system prompt → hijack" to [E1]'s documented behavior (see Drift). The tool-pollution discipline is noted in the explanation.
q5cHow the Infinite Agentic Loop works (/infinite <spec_file> <output_dir> <count> → orchestrator → parallel subagents via the Agent tool → variations → human selection) and what the "infinite prompt" is (a high-order/meta prompt running spec analysis, directory reconnaissance, iteration strategy, parallel coordination).Book pp. 39–44, 49–56[E7], [E10]High — the command, the phases, and the meta-prompt framing are the book's; the explanation carries the corrected IndyDevDan/disler attribution and the community-not-official-feature framing (see Drift).
q6bSynthesis: placing subagents in the multi-agent landscape (in-session delegation = orchestrator-workers; distinct from terminal instances, background agents / Agent view, agent teams [experimental, off by default], dynamic workflows, /batch) and judging the cost (~4× a chat per agent, ~15× multi-agent; fewer truly parallelizable parts than research).Book pp. 35–36 (cost) + Chapter 6 bridge[E2], [E3], [E6], [E7]High — the one enrichment-grounded synthesis question. The token multipliers and the "value high enough" / "fewer parallelizable tasks than research" cautions are from [E6]; the orchestrator-workers name from [E7]; the surrounding landscape (Agent view, agent teams gating, /batch) from [E2]/[E3].

Drift / Corrections Applied

The book is largely current on this chapter's surface (verified against [E1]–[E10]). Most items below are places the lesson completes, renames, or softens the book. None reach the Chapter-5 magnitude.

2026-06-14 accuracy re-audit. An independent audit flagged five over-/under-statements about subagent context composition, invocation methods, the Ctrl+R/Cmd+R keyboard claim, the "description is appended to the main system prompt" implementation claim, and the source-boundary framing of the Infinite Agentic Loop / orchestrator-workers / token-cost numbers. All were verified against the current canonical docs ([E1] sub-agents, [E2] agents, agent-view, interactive-mode, cli-reference) and corrected across the lesson, quiz, this ledger, and the training-output mirror. The new rows below (marked 2026-06-14) record each. The book's original wording is preserved verbatim in extracted-chapters/ and is not edited.
ItemBook positionCurrent / correct positionLesson treatment
Infinite Agentic Loop attribution (CORRECTION)Book names the creator "IndieDevDan" and signs off "Kudos to IndieDev.com" (extract pp. 36, 56).The correct handle is IndyDevDan (GitHub disler), site agenticengineer.com, channel youtube.com/@indydevdan; the repo is github.com/disler/infinite-agentic-loop (MIT). It is a community pattern, not an official Anthropic feature — the book frames it as just "the implementation."§6 uses the correct name/handle, explicitly flags the book's "IndieDevDan / IndieDev.com" misspelling, and labels the pattern as community / not-official with a "verify the exact command against current docs" caveat. q5's explanation carries the corrected attribution.
The "Task tool" renamed to Agent (COMPLETION)The book and the infinite.md command say the main agent spawns subagents using the "task tool" (extract pp. 52, 55).Current Claude Code renamed it the Agent tool; Task remains an alias.§7 says the subagents are spawned "via the Agent tool (the tool formerly called Task)." No book error — a rename completion.
Scope hierarchy is broader than two (COMPLETION)Book teaches exactly two scopes — project .claude/agents/ and user ~/.claude/agents/ (extract pp. 5, 8).Per [E1] the precedence is broader (managed settings > --agents flag > project > user > plugin); project wins over user on name collisions.§1 teaches the two file directories the learner creates, and adds a one-line aside that organization-managed settings and plugins can also supply subagents, with project winning over user.
Frontmatter schema has grown (COMPLETION)Book lists tools, skills, mcp, model, hooks, memory "and others," noting only name/description are required (extract p. 6) — fairly current.Canonical [E1] also documents disallowedTools, permissionMode, maxTurns, mcpServers (canonical name vs the book's mcp), background, effort, isolation: worktree, color, initialPrompt — and the set grows between releases.§1 names several of the additional fields and the further reading explicitly lists more, then links code.claude.com/docs/en/sub-agents for "the current, full schema; the set grows between releases" (soft wording per the project rule).
tools is a genuine allowlist for subagents (CLARIFICATION)Book is correct: "If this section is left empty, the subagent is granted access to all available tools" (extract p. 6) — and listing tools restricts to those.Per [E1]: omit → inherits all; list → restricted to exactly those (plus a disallowedTools denylist). This is the opposite of a Skill's allowed-tools, which only pre-approves listed tools (a grant) without blocking the rest.§1 keeps the book's correct allowlist statement and adds the explicit contrast with a Skill's allowed-tools (ties to the locked-in CLAUDE.md drift note about allowed-tools).
model: inherit is the default (COMPLETION)Book's first example uses model: inherit; the generated code-comedy-carl uses model: sonnet (extract pp. 3, 12) — both fine, but the book doesn't state the default.Per [E1]: valid values are sonnet/opus/haiku/fable/a full model ID/inherit; omitting model defaults to inherit.§1 states the valid values and that omitting model defaults to inherit.
Built-in subagents beyond general-purpose (COMPLETION)Book mentions only the "general-purpose built-in agent" visible via /agents (extract p. 8).Current Claude Code also ships read-only helpers Explore and Plan (plus other helpers).§2 says /agents shows "the built-in agents Claude Code ships with (a general-purpose agent, plus read-only helpers like Explore and Plan)."
Invocation methods (SOFTENING / COMPLETION — expanded 2026-06-14)Book demonstrates the natural-language path and says the agent "can also be invoked through a slash command" (extract p. 9).Per [E1], invocation is a scale, not a fixed list: automatic delegation (description-driven); naming it in natural language; @-mention (requests a specific subagent for one task); and session-wide — claude --agent <name> or the agent setting make the whole main thread adopt that subagent, with --agents JSON for throwaway session-only definitions. /agents manages agents (it isn't how you fire a specific one at a task).§3 presents the methods as a scale from "Claude decides" to "pin it for the session" (no fixed "three"), adds the session-wide --agent/agent/--agents methods, drops the "guarantees one run" wording, and softens the book's slash-command claim; the further reading notes /agents (manage) vs claude agents (the CLI background-session monitor) are different things.
Subagent context composition (CORRECTION — 2026-06-14)Book/extract states the delegation prompt is "the only context the subagent receives" (extract pp. 17, 24: "the only context injected into the subagent").Per [E1] "what loads at startup": a subagent starts fresh (no prior conversation history, invoked skills, or files already read) and works from a delegation message Claude writes — but its initial context also includes its own system prompt + environment details, every level of the CLAUDE.md/memory hierarchy, a git-status snapshot, and any preloaded skills. The built-in Explore and Plan agents skip CLAUDE.md and git status. A forked subagent is the exception that inherits the parent conversation.The frontmatter objective 4, §1's context bullet, §4's opening ("fresh ≠ empty" paragraph), Figure 7.A's labels/aria-label, and q1 (option + explanation) were reworded to replace "only the prompt / its only context" with the fresh-start-plus-what-loads framing, including the Explore/Plan and fork exceptions.
"Description appended to the main system prompt" (CORRECTION — 2026-06-14)Book asserts an internal-implementation detail: "a description is appended to Claude Code's main agent system prompt" (extract p. 24) and bases its security warning on it — "Because the description is appended to the system prompt of Claude Code's main agent, a … definition from an untrusted source could include malicious instructions" (extract p. 27).Current docs ([E1]) do not describe the description as appended to the main system prompt. They state Claude uses the description (with the user request and current context) to decide when to delegate, and composes the delegation message it hands the subagent. The full user message still goes to Claude; Claude writes the subagent's task prompt.§5 Lever 1, Figure 7.B (visible text + aria-label), the §5 "untrusted definitions" paragraph, the common-pitfalls bullet, q4 (option + explanation), and the Figure-7.B ledger entry were reworded to "Claude reads the description to decide when to delegate and to write the task prompt." The security warning is kept but reframed: an untrusted subagent definition can influence routing, prompting, permissions, tools, hooks, MCP, memory, or instructions (a definition controls all of these) — not a proven "main-system-prompt hijack."
Ctrl+R/Cmd+R keyboard claim (CORRECTION — 2026-06-14)An earlier draft of this chapter (not the book) claimed pressing Ctrl+R / Cmd+R "expands the agent view so you can watch a subagent's internal activity."Per the interactive-mode and agent-view docs: in an interactive session, Ctrl+R is reverse command-history search; Ctrl+O toggles the transcript viewer (detailed tool usage/execution). To track in-session subagents, the /agents command has a Running tab (lists live/recently-finished subagents; open or stop them), and a subagent panel appears below the prompt. claude agents opens Agent View for background sessions — a separate surface — where Ctrl+R renames the selected background session.§3's housekeeping note and the practical-exercise Part 2 step were rewritten to use Ctrl+O (transcript viewer) + the /agents Running tab, and to distinguish /agents from claude agents (where Ctrl+R renames). All "Ctrl+R/Cmd+R expand" wording removed from the lesson, exercise, this ledger, and the training-output mirror.
Source boundary: Infinite Loop / orchestrator-workers / token numbers (FRAMING — clarified 2026-06-14)n/a — these are not Claude Code product docs.The Infinite Agentic Loop is a community pattern ([E10], IndyDevDan/disler), the orchestrator-workers taxonomy is from Anthropic's engineering blog ([E7]), and the ~4×/~15× token-cost and ~90% eval figures are from Anthropic's engineering post ([E6]) reporting one internal evaluation. None are official Claude Code docs behavior.These are cited only as clearly-labeled engineering/cookbook/community enrichment ([E6], [E7], [E9], [E10]) in §6–§7, the Further Reading, and the q5/q6 mappings — never under "[E1] docs" or as docs-verified Claude Code behavior. The training-output verification checklist was split so "verified against canonical docs" lists only Claude Code behaviors, with these enrichment items called out separately. Eval numbers carry soft "as reported / internal evaluation" wording.
Context window size (SOFTENING)Book uses a "200K tokens max" worked example (extract pp. 18–19), while also noting models may have 1M/2M/10M-token windows.Limits move with model generations.The preface and §4 soften to "commonly around 200,000 tokens today, larger on some models" per the soft-wording rule, while preserving the book's worked growth illustration.
Canonical docs host (NOTE)Book cites https://docs.claude.com/docs/en/sub-agents (extract p. 2) and https://code.claude.com/docs/en/sub-agents (extract p. 6).The canonical host is code.claude.com; the docs.claude.com / docs.anthropic.com paths mirror/redirect.The lesson and further reading cite code.claude.com throughout.
ReAct / "deep agents" aside & a non-canonical model id (NOTE, not a correction)Book has a "Relationship to React Agents" section with a LangGraph create_react_agent snippet using the model id anthropic:claude-4-7-sonnet-latest (extract p. 7) — a non-canonical/likely-fictional id.n/a — the snippet is illustrative; the model id is not a real canonical Claude id.The lesson keeps only a light conceptual mention of the agents/deep-agents relationship in the preface and does not reproduce the broken model id or the snippet. Recorded here so a reviewer isn't misled by the extract.
Enrichment numbers are eval-specific (soft-wording)n/a — these figures are not in the book.The lesson cites Anthropic's internal evaluation: a multi-agent system outperformed single-agent by ~90% on their research eval; agents use ~4× a chat's tokens and multi-agent systems ~15×; subagents return ~1,000–2,000-token condensed summaries; the "attention budget" / context-rot framing. All drift with model generations.Attributed to "Anthropic's internal evaluation, as reported" / "Anthropic's context-engineering write-up" per the soft-wording rule. Sources [E6]/[E7]/[E8].

Extraction caveat (image-only PDF)

source-pdfs/07-chapter-07.pdf is an image-only PDF — every page is a set of rendered images with no text layer (confirmed: pdftotext -layout and pypdf both returned 0 characters; the image-only check python -c "import pypdf; print(sum(len(p.extract_text() or '') for p in pypdf.PdfReader('source-pdfs/07-chapter-07.pdf').pages))" printed 0). Standard extraction was therefore impossible. The source-of-truth extracted-chapters/07-chapter-07.md was produced by rendering each of the 57 pages to PNG at 150 DPI (PyMuPDF / fitz) into work/07-chapter-07-pages/ and transcribing the images visually. Consequences a reviewer should know:

  • Page markers are reliable (the renderer gave clean per-page boundaries), but printed book page numbers are unknown — <!-- page N --> is the PDF page index, not the book's printed page. There is no .txt mirror for this chapter.
  • The book's figures are screenshots (terminal / editor / browser captures embedded as images, plus the two architecture diagrams in Figs 7.8 and 7.10). They are not transcribed pixel-for-pixel and not reproduced in the lesson (we have no rights, and they're bitmaps). Figure captions and the gist of each figure are preserved in the extract, marked "[Figure: …]". The page-44 six-variation list carries an explicit transcription-uncertainty note in the extract (small source text); the lesson's six variation names match it.
  • The book's stale terms and the creator's misspelling are intentionally preserved verbatim in the extract — the extract retains "task tool," "IndieDevDan," and "Kudos to IndieDev.com" exactly as in the source. Do not edit extracted-chapters/07-chapter-07.md to match the lesson's corrections; it is the verbatim book source-of-truth and is supposed to retain the book's wording. The corrections live only in the lesson, the quiz, this ledger, and the training-output mirror.
  • Re-transcription, not OCR. No OCR engine (tesseract) or PDF rasterizer (pdftoppm/ghostscript) was available locally; PyMuPDF was installed specifically to render the pages. If exact wording matters for a citation, cross-check against the printed book.
Chapter 8: Creating and Customizing Output Styles

Source Ledger — Chapter 8: Creating and Customizing Output Styles

Primary source (the book)

  • Source PDF: source-pdfs/08-chapter-08.pdf (39 pages)
  • Extracted source: extracted-chapters/08-chapter-08.md (visual extraction, with <!-- page N --> markers for all 39 pages). There is no usable .txt for this chapter — see the Extraction caveat at the end.
  • Extraction tool: none of the usual text extractors worked — the Chapter 8 PDF is image-only (each page is composed of rendered images; the image-only check python -c "import pypdf; print(sum(len(p.extract_text() or '') for p in pypdf.PdfReader('source-pdfs/08-chapter-08.pdf').pages))" printed 0). The chapter was extracted by rendering all 39 pages to PNG at 150 DPI with PyMuPDF (fitz) into work/08-chapter-08-pages/ and transcribing them visually into extracted-chapters/08-chapter-08.md. Extraction style: to avoid reproducing a copyrighted Packt chapter at length, the explanatory prose is captured as faithful section-by-section summaries, while every heading, code block, command, YAML/JSON, file path, key name, and flag is captured verbatim (these are the load-bearing/functional elements the lesson needs). Treat code/config/paths in the extract as exact; treat prose as a structural summary, and re-open the page images for exact sentence wording.
  • Book's main sections (from the extract, in order): "Creating a custom output style with Claude Code" (the /output-style picker; built-in Default/Explanatory/Learning; the user-scoped minimal-bullets.md; "How output styles work" = replaces the software-engineering instructions; pp. 1–6); "Why YAML" + "Creating YAML as an output style" (the project-scoped yaml-concise.md; the YAML task-plan example; pp. 6–13); "Creating an advanced project-level output style" (retro-ASCII_blog.md → HTML page; "Automating file generation" = embedding a ## Workflow instruction; pp. 13–19); "Working with multiple output styles" (launching a second instance; specialized output-style workflows; pp. 19–22); "Customizing the status line in Claude Code" (/statusline; the statusLine settings key + uv run ~/.claude/statusline.py; the minimal statusline.py reading output_style; ANSI color; the extended get_last_user_prompt reading transcript_path; pp. 22–34); "The future of AI coding: a team of specialized agents" (multiple instances by role/output-style; the Neo-Genius start-up-team illustration; naming frontend-engineer/backend-engineer/devops/security-review; pp. 35–38); "Summary" (pp. 38–39).

Enrichment sources

The lesson silently incorporates material from the official Claude Code documentation. Per project convention, no inline > Source: or > Enrichment — ... labels appear in the learner-facing lesson — the only in-lesson labelled callouts are the > Analogy — ... boxes. This source ledger is the single source of provenance.

  • [E1] Anthropic docs — Output styles — https://code.claude.com/docs/en/output-styles
  • [E2] Anthropic docs — Customize your status line — https://code.claude.com/docs/en/statusline
  • [E3] Anthropic docs — Settings — https://code.claude.com/docs/en/settings
  • [E4] Anthropic docs — Memory / CLAUDE.md — https://code.claude.com/docs/en/memory
  • [E5] Anthropic docs — CLI reference (--append-system-prompt / --system-prompt) — https://code.claude.com/docs/en/cli-reference
  • [E6] Anthropic docs — How Claude Code uses prompt caching — https://code.claude.com/docs/en/prompt-caching
  • [E7] Anthropic docs — Best practices: run multiple Claude sessions — https://code.claude.com/docs/en/best-practices
  • [E8] Anthropic docs — Subagents — https://code.claude.com/docs/en/sub-agents
  • [E9] Anthropic docs — Agent teams — https://code.claude.com/docs/en/agent-teams

Unlike Chapter 7 (which was largely current), this chapter's central surface had drifted materially — the book's primary command, /output-style, no longer exists (deprecated v2.1.73, removed v2.1.91), and the built-in style list and the custom-style frontmatter both grew. All facts were verified against the canonical docs before authoring (and the load-bearing pages — [E1] output-styles and [E2] statusline — were fetched directly, not taken from a summary). Enrichment is used to (a) correct the removed /output-style command → /config → Output style; (b) complete the built-in style set (add Proactive), the frontmatter (keep-coding-instructions, force-for-plugin), the third managed-policy scope, and the full status-line JSON schema; (c) clarify the system-prompt mechanics (instructions appended; software-engineering block dropped unless keep-coding-instructions: true) and the contrast with CLAUDE.md / --append-system-prompt / subagents / Skills; and (d) reframe honestly the book's "team of specialized agents" against the documented parallel-work tools (subagents / experimental agent teams).

Pedagogical enrichment by the training author

Not from the book and not from the docs — written for this training, inventoried here for separate audit. No inline labels in the lesson except the > Analogy — ... callouts.

  • Newcomer preface (## Before we start — system prompts, output styles, stdin/stdout, and ANSI). Defines system prompt vs user prompt, what an output style and a status line are, stdin/stdout/pipes, JSON vs YAML, frontmatter, ANSI escape codes, and the bridge from Chapter 7 (subagents shape a delegated helper; this chapter reshapes the main session's interface). Grounded in [E1], [E2].
  • Per-section analogies. Six > Analogy — ... callouts, one per numbered section: §1 the dress-code card by the door; §2 the script vs. the sticky note; §3 the form vs. the blank page; §4 the note on the order ticket vs. the conveyor belt (a style's workflow instruction is a request, like a note; a hook is the deterministic conveyor belt); §5 the car dashboard; §6 the open-plan office with labeled desks.
  • Whole-chapter analogy (## The whole chapter in one image — you're at the mixing board). A sustained producer-at-the-mixing-board analogy threading all six sections (choose the format → wire the channels → light the VU meters → staff the booths).
  • Two SVG diagrams (the book's figures are screenshots/illustrations and are not reproduced — we have no rights, and they're image-only besides):
  • Figure 8.A — how an output style rewrites the system prompt: three stacked-block columns (Default; custom with keep-coding-instructions: false → software-engineering block removed, custom instructions appended; custom with true → all kept), plus a footnote that CLAUDE.md is not part of the system prompt (added as a user message after it).
  • Figure 8.B — the status-line data flow: session JSON → stdin → statusline.py (read, pick fields, ANSI) → stdout → the rendered status bar.
  • Each SVG figcaption explicitly notes it is "Pedagogical diagram by this training, not from the book." (See the Diagram-count note below for why this chapter ships two, not three.)
  • Conceptual activity — "Audit and design your own output style." Ten-minute individual exercise: spot a repeated re-prompt, pick the right layer (output style vs CLAUDE.md vs --append-system-prompt vs subagent) using the §2 table, draft frontmatter (with a deliberate keep-coding-instructions decision), draft three body rules (+ an optional ## Workflow rule), and choose scope. Grounded in §1/§2/§4.
  • Practical exercise — "Reshape the interface: two output styles and a live status line." A ~35–45 min hands-on lab on a framework-free, stdlib-only sandbox (~/cct-ch8-lab/ with one tiny greet.py), outside the training repo. Part 1 selects a built-in style via /config (not the removed /output-style) and runs /clear (or starts a new session) so it takes effect — the lab makes the "read once at session start" rule explicit at every style switch; Part 2 hand-writes a project-scoped minimal-bullets.md (select → /clear → re-ask); Part 3 demonstrates keep-coding-instructions (default-false drops the coding behavior; true keeps it); Part 4 builds a status line manually (a hand-written stdlib statusline.py + a statusLine block in project .claude/settings.json) as the primary, self-contained, reversible path, with the /statusline command presented as a faster alternative that generates a script in global ~/.claude/ and updates settings automatically (no project-settings picker). Uses plain python3 (book uses uv run) so no extra installs are required.
Diagram-count note. This chapter intentionally ships two original SVG diagrams (8.A system-prompt rewrite; 8.B status-line data flow). The §6 "team of specialized instances" idea is conveyed through prose, the comparison table, and the labeled-desks analogy rather than a third SVG, because the honest framing (it's the book's metaphor, not a documented architecture) is better carried in text than in a diagram that might imply it's a first-class feature. Earlier chapters shipped 3–4 diagrams; two is a deliberate choice here, not an omission.

Quiz items and learning objectives remain grounded in the book chapter and the labelled enrichment; none of the analogies, diagrams, the activity, or the exercise steps are themselves assessed.

Objective → Source Mapping

Learning ObjectiveSource Section (page)EnrichmentConfidenceNotes
Explain what an output style is (reshapes how Claude responds by modifying the system prompt), name the built-in styles, and select one with /config (the removed /output-style).Book "Creating a custom output style" (pp. 1–5)[E1]HighThe "how responses are structured/delivered" framing and the Default/Explanatory/Learning list are the book's. Proactive, and the /config-not-/output-style selection, are corrected/completed from [E1] (see Drift).
Author a custom style (Markdown + YAML frontmatter; description + keep-coding-instructions; user vs project scope) and explain that selecting it drops the software-engineering instructions unless keep-coding-instructions: true.Book "Creating and reviewing a new output style" + "How output styles work" (pp. 3–6)[E1]HighThe minimal-bullets.md example, the two scope directories, and "removes its default software engineering instructions and substitutes them" are the book's. keep-coding-instructions (default false), the full frontmatter, and the managed-policy scope are completed from [E1] — the book never mentions the flag (see Drift).
Distinguish output styles from CLAUDE.md, --append-system-prompt, subagents, and Skills, and pick the right one.n/a — not in the book as a comparison[E1], [E4], [E5], [E8]High — synthesisThe comparison table is from [E1]'s "Comparisons to related features"; the CLAUDE.md = "user message after the system prompt" contrast is from [E1]/[E4]; the flags from [E5]; subagents from [E8] (Chapter 7). The book does not contrast these tools — this is enrichment.
Use a YAML structured-output style and build an advanced style that carries workflow instructions (HTML generation + a request to save the file), understanding it's a nudge not a guarantee.Book "Why YAML" / "Creating YAML as an output style" + "Creating an advanced project-level output style" / "Automating file generation" (pp. 6–19)[E1]HighThe YAML "format-as-protocol" argument, the yaml-concise.md/retro-ASCII_blog.md files, and the ## Workflow instruction are the book's. Softened (see Drift): the lesson reframes the embedded ## Workflow step as an instruction (system-prompt text), not deterministic execution — whether it runs depends on tools/permissions/session mode and Claude following it; for must-run steps the lesson points to hooks/scripts. The book's "no callable logic is introduced" / "no code or plugins" framing is kept as the book's wording but not presented as a guaranteed workflow engine.
Customize the status line: configure via /statusline or the statusLine settings key; explain the stdin-JSON → script → stdout flow (model, context, cost, output style, transcript_path); ANSI color.Book "Customizing the status line" → "Implementing the status line logic" / "ANSI color support" / the get_last_user_prompt extension (pp. 22–34)[E2]HighThe /statusline command, the statusLine config block, the minimal/extended Python scripts, and ANSI color are the book's (and current). The full JSON schema and the output_style.name nesting are completed/corrected from [E2] (book's input_data.get("output_style", "default") reads a bare string; current schema nests .name) — see Drift.
Describe the "team of specialized agents" idea and judge it honestly against subagents / agent teams.Book "Working with multiple output styles" + "The future of AI coding: a team of specialized agents" (pp. 19–22, 35–38)[E7], [E8], [E9]High — synthesisThe multiple-instances-by-role vision is the book's. The honest reframe (one-instance-per-style is the book's metaphor, not a documented architecture; subagents [stable] / agent teams [experimental, gated] are the documented parallel-work tools) is from [E7]/[E8]/[E9] (see Drift).

Lesson Section → Source Mapping

Lesson sectionSource locationEnrichmentConfidenceNotes
Preface — system prompt vs user prompt; output style; status line; stdin/stdout; JSON/YAML; frontmatter; ANSI; bridge from Chapter 7Concepts introduced across the book chapter[E1], [E2]HighPedagogical re-framing for newcomers. The Chapter-7 bridge is the lesson's.
"Why this chapter matters" — engineering the communication protocol; the "moves from consuming to designing output" thesis; currency note on /output-style removalBook intro (pp. 1, 15)[E1]HighThe thesis is the book's; the /output-style-removed currency note is from [E1] (see Drift).
§1 — what an output style is; built-in styles; selecting via /config; the minimal-bullets.md file; scopes; frontmatter fieldsBook pp. 1–5[E1]HighBook's example preserved; Proactive, /config selection, keep-coding-instructions/force-for-plugin, and the managed-policy scope from [E1] (see Drift).
§1 — analogy: the dress-code card by the doorn/a — pedagogicaln/an/aOriginal.
§2 — how output styles work (system-prompt modification; instructions appended; software-engineering block dropped unless keep-coding-instructions: true); read once at session start; the comparison tableBook "How output styles work" (pp. 5–6)[E1], [E4], [E5], [E6], [E8]HighThe "replaces the software-engineering instructions" mechanic is the book's; the keep-coding-instructions escape hatch, "appended to the end," "read once at session start," and the full comparison table are from [E1] (table) / [E4]/[E5]/[E8] (see Drift).
§2 — Figure 8.A (system-prompt rewrite; keep-coding-instructions; CLAUDE.md footnote)n/a — pedagogical diagram[E1]n/aOriginal SVG.
§2 — analogy: the script vs. the sticky noten/a — pedagogicaln/an/aOriginal.
§3 — Why YAML; the yaml-concise.md style; the YAML task-plan example; format-as-protocol; project scopeBook pp. 6–13 (incl. the auth-bug YAML plan and the "definition/location/file_structure/functionality" response)—HighFaithfully the book's; the Kubernetes/Docker-Compose comparison is the book's own. No correction.
§3 — analogy: the form vs. the blank pagen/a — pedagogicaln/an/aOriginal.
§4 — advanced HTML style (retro-ASCII_blog.md); adding the ## Workflow instruction (save + open); "no callable logic"; the nudge-not-a-guarantee caveat + the hook/script pointerBook pp. 13–19[E1]HighThe style file, the ## Workflow snippet (book p. 18, "Save the HTML file after writing it…"), and "no callable logic is introduced" are the book's. Softened (see Drift): the lesson reframes the workflow step as a system-prompt instruction — a strong nudge, not deterministic execution (depends on tools/permissions/session mode + Claude following it) — and explicitly points to hooks/scripts for steps that must run every time. The long style file is trimmed to representative blocks.
§4 — analogy: the note on the order ticket vs. the conveyor beltn/a — pedagogicaln/an/aOriginal. Restates that a style's workflow instruction is a request (a note), while a hook/script is the deterministic mechanism (the belt).
§5 — status line: /statusline + statusLine settings block; stdin-JSON→script→stdout; minimal statusline.py; output_style.name correction; ANSI; the get_last_user_prompt/transcript_path extension; the full JSON schemaBook pp. 22–34[E2]HighThe command, config block, both Python scripts, and ANSI are the book's and current. The output_style.name nesting correction and the richer field list are from [E2] (see Drift). Corrected (see Drift): the lesson describes /statusline as "generates a script in ~/.claude/ and updates your settings automatically" per [E2] — it does not repeat the book's "spawns a sub-agent" claim (unsupported by the docs) and does not imply a project-settings picker. The book targets global ~/.claude/settings.json; [E2] confirms project-scoped .claude/settings.json is equally valid.
§5 — Figure 8.B (status-line data flow)n/a — pedagogical diagram[E2]n/aOriginal SVG.
§5 — analogy: the car dashboardn/a — pedagogicaln/an/aOriginal.
§6 — multiple instances by role/output-style; status line to tell them apart; the "configurable system, not a fixed interface" thesis; the honest reframe to subagents / agent teamsBook pp. 19–22, 35–38[E7], [E8], [E9]HighThe vision and the thesis are the book's. The honest reframe (book's metaphor vs documented subagents/agent teams; agent teams experimental + gated) is from [E7]/[E8]/[E9] (see Drift).
§6 — analogy: the open-plan office with labeled desksn/a — pedagogicaln/an/aOriginal.
Whole-chapter analogy: you're at the mixing boardn/a — pedagogical synthesisn/an/aOriginal.
Activity: Audit and design your own output stylen/a — pedagogical[E1]n/aOriginal. Grounded in §1/§2/§4.
Practical exercise: two output styles + a live status line (stdlib sandbox)Book pp. 1–34 recombined into a framework-free lab[E1], [E2]High — original sequencingEvery step grounded in the book + [E1]/[E2]. Sandbox ~/cct-ch8-lab/ is outside the training repo, uses no npm/Node, and configures the status line at project scope for reversibility.

Unsupported / Pedagogical-Only Claims

Statements in the learner-facing lesson that are not from the book and not directly from the labelled enrichment, listed for isolated audit.

ItemJustification
Dress-code-card analogy (§1)Pedagogical analogy. No external claim.
Script-vs-sticky-note analogy (§2)Pedagogical analogy. Restates output style (system prompt) vs CLAUDE.md (user message after).
Form-vs-blank-page analogy (§3)Pedagogical analogy. Restates the YAML format-as-protocol argument.
Order-ticket-vs-conveyor-belt analogy (§4)Pedagogical analogy. Restates that a style's workflow instruction is a request (a note), not a guarantee, and a hook/script is the deterministic mechanism (the belt).
Car-dashboard analogy (§5)Pedagogical analogy. Restates the status-line data flow.
Labeled-desks analogy (§6)Pedagogical analogy. Restates the multi-instance idea + the coordination caveat.
Mixing-board whole-chapter analogyPedagogical synthesis. No new claims.
Figures 8.A–8.B (SVGs)Original SVGs. Visually restate the system-prompt rewrite and the status-line data flow.
The greet.py sandbox file (practical exercise)Authored for this training as a trivially-flawed function (no validation/type hint) to give the styles something to talk about and edit.
Using project-scoped .claude/settings.json for the lab's status lineLesson choice for reversibility/self-containment; [E2] confirms project scope is valid. The book uses global ~/.claude/settings.json.
Using plain python3 to run the status-line scriptLesson choice so no extra tooling is needed; the script is stdlib-only. The book runs it via uv run.

Quiz Item → Source Mapping

Quiz IDAnswerItemSource locationEnrichmentConfidence
q1aWhat an output style is (modifies the system prompt to change how Claude responds) and how to select one now (/config, not the removed /output-style); the built-in styles incl. Proactive.Book pp. 1–5[E1]High — the definition and built-in trio are the book's; the /config selection, the /output-style removal, and Proactive are from [E1] (see Drift).
q2bCustom-style structure (Markdown + YAML frontmatter; user/project scope) and keep-coding-instructions (default false; drops the software-engineering instructions unless true).Book pp. 3–6[E1]High — the file structure and "removes the SE instructions" are the book's; keep-coding-instructions (the answer's crux) is from [E1] (book omits it).
q3cWhy respond in YAML (format-as-protocol: dependencies→nesting, priority→ordering, structure mirrors the problem; machine-readable).Book pp. 6–12—High — entirely the book's argument.
q4bThe advanced HTML style carries workflow instructions (ask Claude to save the file + open the browser) in the style definition — a strong nudge, not a guaranteed action (depends on tools/permissions/session + Claude following it); for must-run steps, use a hook/script.Book pp. 13–19[E1]High — the book's "Automating file generation" / "no callable logic is introduced," softened per the Drift table (execution is not guaranteed; hooks/scripts are the deterministic path).
q5aStatus-line config (/statusline or the statusLine block) and the stdin-JSON → script → stdout flow (model/style/context/cost/transcript_path); ANSI color.Book pp. 22–34[E2]High — the command, config, scripts, and ANSI are the book's; the explanation notes the output_style.name nesting correction from [E2].
q6bSynthesis: output style vs CLAUDE.md vs --append-system-prompt vs subagent vs Skill, plus the honest multi-instance framing (subagents stable / agent teams experimental-gated; "one instance per output style" is the book's metaphor).Book pp. 19–38 + the layer distinctions[E1], [E4], [E5], [E7], [E8], [E9]High — the one enrichment-grounded synthesis question. The comparison is from [E1]/[E4]/[E5]/[E8]; the parallel-work reframe and the CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS gating from [E7]/[E9].

Drift / Corrections Applied

This chapter's central surface had drifted materially since the book — unlike Chapter 7. The book's primary command was removed, and the built-in styles and frontmatter both grew. All items verified against the canonical docs ([E1] output-styles and [E2] statusline fetched directly). The book's original wording is preserved verbatim in extracted-chapters/ and is not edited.

2026-06-15 accuracy re-audit. A follow-up review (verified against [E1] output-styles, [E2] statusline, [E3] settings, [E5] cli-reference) tightened five things across the lesson, quiz, this ledger, and the training-output mirror: (1) every place that switched an output style now makes the /clear-or-new-session step explicit before observing the change (it was stated as a rule but the practical steps implied immediate effect); (2) the embedded-workflow claims were softened from "the style carries out a procedure on every response" to "the style asks Claude to — an instruction, not a guaranteed action — and for must-run steps use a hook/script"; (3) the book's "/statusline spawns a sub-agent" claim was dropped (unsupported by [E2]; the docs say it generates a script in ~/.claude/ and updates settings automatically) and the practical exercise no longer implies a project-settings picker; (4) the settings-precedence summary was corrected from the wrong "managed → user → project → local" to the documented managed → command-line args → local → project → user; (5) the §4 analogy was reworked (rubber-stamp → order-ticket-note vs. conveyor-belt) to carry the nudge-vs-guarantee distinction. The new rows below (marked 2026-06-15) record each. The verbatim extract was not edited.
ItemBook positionCurrent / correct positionLesson treatment
/output-style command removed (CORRECTION — central)The book lists and switches output styles with a standalone /output-style command throughout (extract pp. 2, 5–6, and every figure).The standalone /output-style command was deprecated in v2.1.73 and removed in v2.1.91. You now switch styles via /config → Output style (saved to .claude/settings.local.json) or by setting the outputStyle field in a settings file.A prominent currency note in "Why this chapter matters" plus §1 teach /config/outputStyle as current and flag /output-style as removed (with the version). The practical-exercise Part 1 and the common-pitfalls call it out. q1 makes the correction part of the correct answer. Soft-worded ("verify against the docs") per the project rule.
Built-in styles: Proactive added (COMPLETION)Book lists three built-ins: Default, Explanatory, Learning (extract pp. 2–3) — and flags in a margin note that the set "may evolve over time."Current [E1] lists four: Default, Proactive (executes immediately, prefers action over planning; still shows permission prompts), Explanatory, Learning.§1 lists all four with one-line descriptions, quotes the book's own "may evolve" note, and tells the learner to check /config on their install.
keep-coding-instructions frontmatter field (COMPLETION — load-bearing)The book says selecting a custom style "removes its default software engineering instructions and substitutes them" (extract p. 5) but never mentions any way to keep them.Per [E1], a custom style drops Claude Code's software-engineering instructions only if keep-coding-instructions is false (the default); set it true to keep both the engineering brain and your custom instructions.§2 is built around this field (with Figure 8.A and the Diagrams first example), and the practical-exercise Part 3 makes the learner feel the difference. q2's correct answer hinges on it. Framed as the field "the book never mentions."
Custom-style frontmatter & third scope (COMPLETION)Book shows only a description frontmatter line and two scopes (user ~/.claude/output-styles/, project .claude/output-styles/) (extract pp. 3–4, 10).[E1] documents frontmatter name, description, keep-coding-instructions, force-for-plugin, and a third managed-policy location (plus plugins shipping styles in output-styles/).§1 lists the frontmatter fields and notes the managed-policy scope + plugin styles as a parenthetical; the two user-authored scopes stay the focus.
Output-style ↔ system-prompt mechanics (CLARIFICATION)Book says the style "replaces parts of Claude Code's system prompt" and "the modified system prompt is sent directly to the LLM with each request" (extract pp. 5–6) — correct but partial.[E1]: instructions are appended to the end of the system prompt; the style is read once at session start (changes apply after /clear/restart); reminders keep Claude adhering.§1/§2 state "appended to the end" and "read once at session start"; the practical exercise notes the take-effect-after-/clear behavior. Grounded in [E1]/[E6].
Output style vs CLAUDE.md / flags / subagents / Skills (COMPLETION — synthesis)The book does not contrast output styles with these other tools.[E1]'s "Comparisons to related features" table: output style modifies the system prompt; CLAUDE.md adds a user message after it; --append-system-prompt appends one-off; agents = scoped helper; Skills = on-demand.§2 reproduces the comparison table and stresses the output-style-vs-CLAUDE.md distinction ("for project conventions, use CLAUDE.md instead"). q6 is the synthesis question. Pure enrichment, labeled here.
Status-line JSON field is output_style.name (CORRECTION)The book's minimal script reads a bare string: style = input_data.get("output_style", "default") (extract p. 25).Per [E2], the field is nested: output_style.name. The book's read returns the dict, not the name.§5 reproduces the book's one-liner, then explicitly corrects it: a robust current read is input_data.get("output_style", {}).get("name", "default"). The practical-exercise hand-written script uses the nested field; q5's explanation notes it; common-pitfalls flags it.
Status-line JSON schema is much larger (COMPLETION)Book surfaces output_style and transcript_path (extract pp. 25, 29).[E2] documents a large schema: model.display_name/id, output_style.name, context_window.used_percentage/remaining_percentage/context_window_size, cost.total_cost_usd, workspace.current_dir/repo, transcript_path, and conditional agent/pr/worktree/rate_limits.§5 lists the richer field set and links [E2] for the current schema (soft-worded — "the schema grows between releases").
Status-line settings scope (SOFTENING)Book points the statusLine config at global ~/.claude/settings.json (extract pp. 23–24).[E2]: both user (~/.claude/settings.json) and project (.claude/settings.json) are valid.§5 notes project scope is also valid; the practical exercise uses project scope for reversibility. The book's global path is preserved as the book's choice.
uv run vs python3 (NOTE, not a correction)Book runs the status-line script via the UV package manager (uv run ~/.claude/statusline.py, extract pp. 23–24).A status line can run any executable; the book's script is stdlib-only, so plain python3 works without installing uv.§5 keeps the book's uv run example and the practical exercise uses python3 so no extra install is needed — both noted.
"Team of specialized agents" framing (FRAMING / SOFTENING)The book presents running one instance per role/output-style as the path to a coordinated "team of specialized agents" (extract pp. 19–22, 35–38).Per [E7]/[E8]/[E9]: output styles are per-session (so styled instances are real and useful), but the documented way to do coordinated, role-specialized parallel work is subagents (stable) or agent teams (experimental, disabled by default behind CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS). "One instance per output style" is the book's metaphor, not a documented architecture; the parallel-work docs never coordinate by output style.§6 takes the vision seriously and draws the honest line (metaphor vs documented tools; agent teams experimental + gated). The closing analogy and q6 carry the same nuance. The thesis ("a configurable system, not a fixed interface") is kept as the book's.
Output-style switch needs /clear/new session — made explicit (CLARIFICATION — 2026-06-15)The book switches styles with /output-style and shows the new style taking effect in the same session.Per [E1], the output style is read once at session start; a change takes effect after /clear or a new session.Row above (system-prompt mechanics) already stated the rule; the 2026-06-15 re-audit made it operational — practical-exercise Parts 1–4 now insert an explicit /clear-or-new-session step before observing any style change, the "Expected outcome" lines note that asking without clearing returns the old style, and the success-checklist items name the /clear step. The common-pitfalls "read at session start" item is retained.
Embedded-workflow determinism softened (SOFTENING — 2026-06-15)The book frames the ## Workflow instruction as the style reliably saving/opening files ("Claude Code generates the HTML page, writes it to disk, and opens it"; "no callable logic is introduced").An output style is system-prompt text: it can ask Claude to save a file / open a browser, but execution still depends on Claude's available tools, the user's permissions, the session mode, and Claude following the instruction. It's a strong nudge, not a guaranteed action; for deterministic per-event execution, the documented mechanism is a hook or script, not an output style.§4 (heading "asks for more… embedded workflow instructions"), its prose, the §4 analogy (order-ticket note vs. conveyor belt), frontmatter objective 4, the activity step-4 note, and q4 (option + explanation) were all reworded from "carries out a procedure / on every response / the instructions are the program" to "asks Claude to… nudge-not-guarantee… use a hook/script for must-run steps." The book's "no callable logic"/"no code or plugins" wording is kept only as the book's phrasing, not as a guaranteed-workflow claim.
/statusline "spawns a sub-agent" claim dropped + no project-settings picker (CORRECTION — 2026-06-15)The book says running /statusline "initializes and spawns a sub-agent" that inspects settings and writes the script (extract pp. 23–24); an earlier draft of the lesson repeated this and had the lab choose "project settings" from the command.Per [E2], the /statusline command "accepts natural language instructions… generates a script file in ~/.claude/ and updates your settings automatically." The docs do not describe a helper subagent, and there is no documented project-settings picker — project-scoped .claude/settings.json is a supported manual configuration path.§5 now says /statusline "generates a script in ~/.claude/ and updates your settings automatically" (no subagent claim). Practical-exercise Part 4 makes the manual project-scoped .claude/settings.json path primary (self-contained/reversible) and presents /statusline as a faster alternative that writes to global ~/.claude/ with no project picker.
Settings precedence corrected (CORRECTION — 2026-06-15)n/a — not in the book; an earlier draft's Further Reading summarized precedence as "managed → user → project → local."Per [E3], highest→lowest is: Managed → command-line arguments → Local (.claude/settings.local.json) → Project (.claude/settings.json) → User (~/.claude/settings.json) (permission rules are the exception — they merge across scopes rather than override).The Further Reading "Settings" bullet was corrected to the documented order with the permission-merge caveat. (No other artifact stated a precedence order.)
Canonical docs host (NOTE)n/aThe canonical host is code.claude.com; docs.claude.com / docs.anthropic.com mirror/redirect.The lesson and further reading cite code.claude.com throughout.

Extraction caveat (image-only PDF, summarized prose)

source-pdfs/08-chapter-08.pdf is an image-only PDF — every page is a set of rendered images with no text layer (the image-only check printed 0). Standard extraction was impossible. The source-of-truth extracted-chapters/08-chapter-08.md was produced by rendering each of the 39 pages to PNG at 150 DPI (PyMuPDF / fitz) into work/08-chapter-08-pages/ and transcribing the images visually. Consequences a reviewer should know:

  • Mixed-fidelity extract. To avoid reproducing a copyrighted Packt chapter at length, the explanatory prose in the extract is captured as faithful section-by-section summaries, while headings, code blocks, commands, YAML/JSON, file paths, key names, and flags are verbatim (these are the functional elements the lesson depends on). Treat code/config/paths as exact; treat prose as a structural summary. If exact sentence wording is needed for a citation, re-open the page images in work/08-chapter-08-pages/.
  • Page markers are reliable (clean per-page boundaries), but printed book page numbers are unknown — <!-- page N --> is the PDF page index, not the book's printed page. There is no .txt mirror.
  • The book's figures are screenshots/illustrations (terminal/editor/browser captures, plus the "Human–AI collaboration" and "Neo-Genius" illustrations). They are not transcribed pixel-for-pixel and not reproduced in the lesson (we have no rights, and they're bitmaps). Figure captions and the gist are preserved in the extract as [Figure: …] placeholders. The two lesson diagrams are original pedagogical SVGs.
  • A few code regions were screenshots (Figs 8.12/8.17 of statusline.py); the same code is given in clean body text on pp. 25–26 and 32–33, which is what the lesson uses. Two prose lines were partly cut by the page fold/UI chrome (the page-18 ## Workflow snippet; the page-10 yaml-concise description: line) — captured as far as legible and noted in the extract.
  • Re-transcription, not OCR. No OCR engine or PDF rasterizer was available locally; PyMuPDF was installed specifically to render the pages. If exact wording matters for a citation, cross-check against the printed book.
Chapter 9: Understanding Agent Skills

Source Ledger — Chapter 9: Understanding Agent Skills

Primary source (the book)

  • Source PDF: source-pdfs/09-chapter-09.pdf (30 pages)
  • Extracted source: extracted-chapters/09-chapter-09.md (visual extraction, <!-- page N --> markers for all 30 pages). There is no usable .txt for this chapter — see the Extraction caveat at the end.
  • Extraction tool: the Chapter 9 PDF is image-only (the image-only check python -c "import pypdf; print(sum(len(p.extract_text() or '') for p in pypdf.PdfReader('source-pdfs/09-chapter-09.pdf').pages))" printed 0). Extracted by rendering all 30 pages to PNG at 150 DPI with PyMuPDF (fitz) into work/09-chapter-09-pages/ and transcribing visually. Mixed-fidelity: headings, code, commands, YAML/SKILL.md contents, file paths, key names, flags, and table cells are verbatim; explanatory prose is captured as faithful section-by-section summaries (to avoid reproducing a copyrighted chapter at length). Treat code/config/paths/tables as exact; treat prose as a structural summary, and re-open page images for exact sentence wording.
  • Book's main sections (from the extract, in order): "The gist of agent skills" (the HookHub baseline; Scenario 1 styling without skills → prompting directly / the CLAUDE.md-bloat trap; Scenario 2 styling with skills → the brand-guidelines skill from anthropics/skills, installed via the plugin marketplace; progressive context loading; pp. 1–9); "Diving deeper into agent skills" (the git-pushing skill from mhattingpete/claude-skills-marketplace; the smart_commit.sh script; opinionated workflows; "a skill is a packaging mechanism — deterministic scripts, AI calls, or both"; editing When to Use doesn't change selection; enabling automatic approval via settings.local.json; modifying the script to call the Claude CLI (claude -p); breaking the directory structure → recovery; context: fork / agent / disable-model-invocation; pp. 9–24); "Comparing agent skills with other agent primitives" (Skills vs MCP vs subagents vs slash commands; Table 9.1; pp. 25–29); "Summary" (pp. 29–30).

Enrichment sources

The lesson silently incorporates material from the official Claude Code docs and the Anthropic engineering blog. Per project convention, no inline > Source: / > Enrichment — … labels appear in the learner-facing lesson — the only in-lesson labelled callouts are the > Analogy — … boxes. This ledger is the single source of provenance.

Official Claude Code behavior (authoritative):

  • [E1] Anthropic docs — Skills — https://code.claude.com/docs/en/skills
  • [E2] Anthropic docs — MCP — https://code.claude.com/docs/en/mcp
  • [E3] Anthropic docs — Subagents — https://code.claude.com/docs/en/sub-agents
  • [E4] Anthropic docs — Commands — https://code.claude.com/docs/en/commands
  • [E5] Anthropic docs — Plugins — https://code.claude.com/docs/en/plugins
  • [E6] Anthropic Agent SDK — Agent Skills (quickstart) — https://platform.claude.com/docs/en/agents-and-tools/agent-skills/quickstart

Enrichment / context (NOT official Claude Code behavior — clearly labelled as background):

  • [E7] Agent Skills open standard — https://agentskills.io
  • [E8] Anthropic engineering — Equipping agents for the real world with Agent Skills — https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
  • [E9] Anthropic engineering — Code execution with MCP / Effective context engineering for AI agents — https://www.anthropic.com/engineering/code-execution-with-mcp, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
  • [E10] Community — LangChain DeepAgents — https://docs.langchain.com/labs/deep-agents/overview
  • [E11] Community — claude-skills-marketplace by mhattingpete (Apache-2.0) — https://github.com/mhattingpete/claude-skills-marketplace

The book is broadly current on the skills concept (skills, progressive disclosure, scripts, the primitive comparison all hold), but several specifics had drifted or needed sharpening; all Claude Code behavior was verified against [E1]–[E6] before authoring (and the load-bearing skills page [E1] was fetched directly during a follow-up accuracy pass — see Drift / Corrections Applied). Source-boundary discipline: Claude Code behavior claims rest on [E1]–[E6]; engineering posts, the open standard, LangChain, and community marketplaces ([E7]–[E11]) are used only as enrichment/context and are never presented as official Claude Code behavior. Launch dates and token figures are treated as book/announcement context, not docs-verified facts.

Pedagogical enrichment by the training author

Not from the book and not from the docs — written for this training, inventoried here for separate audit.

  • Newcomer preface (## Before we start — skills, "primitives," progressive disclosure, and the CLI). Defines the bridge from Chapter 3 (skills introduced mechanically there; this chapter is the architecture), "primitive," the context window (recap), progressive disclosure (one-line), and claude -p. Grounded in [E1], and Chapters 3/4/7 continuity.
  • Per-section analogies. Five > Analogy — … callouts, one per numbered section: §1 the recipe card in the kitchen drawer; §2 the library with a card catalog; §3 the appliance button with a program behind it; §4 the assistant with a playbook who isn't a robot; §5 four tools on one workbench.
  • Whole-chapter analogy (## The whole chapter in one image — the well-run workshop). A sustained workshop analogy threading all five sections (don't bury the bench → cards drive machines → good workers don't freeze → right tool, right job).
  • Two SVG diagrams (the book's figures are screenshots and are not reproduced):
  • Figure 9.A — progressive disclosure in three stages (listing at startup → body on selection, persists in-session → bundled file on demand), with a lean-context panel. figcaption notes selection reads the listing (the description).
  • Figure 9.B — a skill as packaging: main agent selects skill → skill runs script → deterministic path or AI path (claude -p) → commit; with the agent-reasoning backstop (recovery possible, not guaranteed) and a "use a hook when a step must run every time" note.
  • Each figcaption explicitly notes it is "Pedagogical diagram by this training, not from the book."
  • Conceptual activity — "Decide skill, subagent, MCP, or neither." Ten-minute exercise practising the §5 routing judgment + drafting a description. Grounded in §5/[E1].
  • Practical exercise — "Build a skill that bundles a script, then make it think." A ~35–45 min framework-free, stdlib-only lab (~/cct-ch9-lab/): build a project-level repo-brief skill with a bundled stats.sh (referenced via ${CLAUDE_SKILL_DIR}), prove selection follows the listing (Part 2), upgrade the script to call claude -p with a fallback (Part 3), and break the path to observe recovery as a capability (Part 4). No npm/Node, no accounts. Distinct from Chapter 3's commit-summary exercise (which taught making a slash-command skill) — Ch9's focuses on scripts, progressive disclosure, and deterministic-vs-AI.

Quiz items and learning objectives remain grounded in the book chapter and the labelled enrichment; none of the analogies, diagrams, the activity, or the exercise steps are themselves assessed.

Objective → Source Mapping

Learning ObjectiveSource Section (page)EnrichmentConfidenceNotes
Explain what an agent skill is (a SKILL.md directory + optional scripts/resources; auto-invoked on description match; packaging, not intelligence).Book "The gist of agent skills" (pp. 1–9)[E1]HighThe "procedural knowledge container" + packaging framing and the prompt-vs-skill contrast are the book's; the SKILL.md directory layout and invocation match [E1].
Describe progressive disclosure (listing at startup → body on selection, persists in-session → files on demand) and that selection follows the listing (description primary, when_to_use appended, first-paragraph fallback).Book "Diving deeper" — the When to Use experiment + the progressive-disclosure model (pp. 16–18, 25)[E1]HighThe 3-stage model and the body-edit experiment are the book's. Corrected from [E1]: selection follows the listing (not "frontmatter only"); body persists in-session after load (book/early-draft implied it could vanish). See Drift.
Build a project-level skill with a bundled script; recognize a skill is packaging (deterministic, AI, or both).Book "Creating a project-level custom skill" / "Reviewing the script" (pp. 13–14, 20)[E1]HighEntirely the book's (the git-pushing/smart_commit.sh build and the "packaging mechanism" thesis). Script reference switched to ${CLAUDE_SKILL_DIR} per [E1] (see Drift).
Compose deterministic + AI via claude -p; explain recovery is possible, not guaranteed; use hooks for deterministic enforcement.Book "Modifying the script to use the Claude CLI" + "Breaking the expected structure" (pp. 20–24)[E1]HighThe layered system and the break-the-structure demo are the book's. Softened per [E1]: skills are instructions, not deterministic enforcement; recovery is agent judgment, not guaranteed; hooks are the deterministic path. See Drift.
Place skills among primitives (Skills vs MCP vs subagents vs slash commands); apply the routing rule of thumb.Book "Comparing agent skills with other agent primitives" + Table 9.1 (pp. 25–29)[E1], [E2], [E3], [E4]High — synthesisThe comparison and rule-of-thumb are the book's. Corrected: MCP defers tool definitions by default (tool search), and custom slash commands are merged into skills — the book's Table 9.1 is partly stale on both. See Drift.

Lesson Section → Source Mapping

Lesson sectionSource locationEnrichmentConfidenceNotes
Preface — skills/primitives/progressive disclosure/claude -p; bridge from Chapter 3Concepts across the chapter[E1]HighPedagogical framing; the Chapter-3 bridge is the lesson's.
"Why this chapter matters" — wrong-tool traps; progressive disclosure as the reason for a whole chapter; currency note (skills are cross-product)Book intro + summary (pp. 1–2, 29)[E1], [E7]HighThesis is the book's; the cross-product/open-standard framing is labelled background ([E7]). Hard launch dates removed (see Drift).
§1 — what a skill is; SKILL.md directory; the git-pushing frontmatter; opinionated workflow; Scenario 1 vs 2Book pp. 1–9[E1]HighBook's worked contrast preserved. ${CLAUDE_SKILL_DIR} used for the script path (book uses a relative path); "enforces" softened to "guides"; "context goes away again" corrected (body persists in-session). See Drift.
§1 — analogy: the recipe card in the kitchen drawern/a — pedagogicaln/an/aOriginal.
§2 — progressive disclosure (3 stages, persistence, compaction note); selection follows the listing; the When to Use experimentBook pp. 16–18, 25[E1]HighCorrected per [E1]: "selection driven entirely by the frontmatter" → "Claude routes on the listing — description primary, when_to_use appended, first-paragraph fallback"; added in-session persistence + compaction re-attachment; removed token counts. See Drift.
§2 — Figure 9.A (progressive disclosure)n/a — pedagogical diagram[E1]n/aOriginal SVG; labels/aria reflect the listing + persistence corrections.
§2 — analogy: the library with a card catalogn/a — pedagogicaln/an/aOriginal.
§3 — bundling scripts; "packaging mechanism, not intelligence"; the static smart_commit.shBook pp. 9, 13–14, 20[E1]HighBook's thesis preserved; script path uses ${CLAUDE_SKILL_DIR}; "guides toward the script" framing + the hook caveat added.
§3 — analogy: the appliance button with a program behind itn/a — pedagogicaln/an/aOriginal.
§4 — claude -p composition (the layered system); recovery as a capability; context: fork/agent/disable-model-invocation; the two permissionsBook pp. 20–24[E1]HighLayered system + break-the-structure are the book's. Softened: recovery not guaranteed; hooks for deterministic enforcement. context: fork noted to return a summary per [E1]. See Drift.
§4 — Figure 9.B (deterministic/AI/backstop)n/a — pedagogical diagram[E1]n/aOriginal SVG; backstop framed as non-guaranteed.
§4 — analogy: the assistant with a playbook who isn't a robotn/a — pedagogicaln/an/aOriginal; explicitly non-guaranteed recovery + hook caveat.
§5 — Skills vs MCP vs subagents vs slash commands; the consolidated table; rule of thumbBook pp. 25–29 + Table 9.1[E1], [E2], [E3], [E4]HighComparison is the book's; the consolidated table corrects MCP (tool-search deferral) and notes slash-commands-merged-into-skills. See Drift.
§5 — analogy: four tools on one workbenchn/a — pedagogicaln/an/aOriginal.
Whole-chapter analogy: the well-run workshopn/a — pedagogical synthesisn/an/aOriginal.
Activity: Decide skill, subagent, MCP, or neithern/a — pedagogical[E1]n/aOriginal; grounded in §5.
Practical exercise: build a skill + script, then make it think (stdlib sandbox)Book pp. 9–24 recombined into a framework-free lab[E1]High — original sequencingEvery step grounded in the book + [E1]; ${CLAUDE_SKILL_DIR} used in the skill body; recovery framed as non-guaranteed.

Unsupported / Pedagogical-Only Claims

ItemJustification
Recipe-card analogy (§1)Pedagogical analogy. Restates "skill = consistent, packaged procedure."
Card-catalog analogy (§2)Pedagogical analogy. Restates progressive disclosure.
Appliance-button analogy (§3)Pedagogical analogy. Restates "a skill is packaging; the script is the program."
Playbook analogy (§4)Pedagogical analogy. Restates instruction-not-enforcement + non-guaranteed recovery + the hook caveat.
Four-tools-on-a-workbench analogy (§5)Pedagogical analogy. Restates the primitive comparison.
Workshop whole-chapter analogyPedagogical synthesis. No new claims.
Figures 9.A–9.B (SVGs)Original SVGs. Visually restate progressive disclosure and skill-as-packaging.
The repo-brief skill + stats.sh (practical exercise)Authored for this training as a framework-free, stdlib-only stand-in for the book's git-pushing/Next.js demo.
The consolidated comparison table (§5)Built from [E1]–[E4] (current docs), correcting the book's Table 9.1 (MCP deferral; slash-commands-merged). The book's table is recorded verbatim in the extract.

Quiz Item → Source Mapping

Quiz IDAnswerItemSource locationEnrichmentConfidence
q1aWhat a skill is (a SKILL.md directory + scripts/resources; auto-invoked on description match; packaging, not intelligence).Book pp. 1–9[E1]High
q2bProgressive disclosure (listing → body, persists in-session → files); selection follows the listing (description primary, when_to_use appended, first-paragraph fallback).Book pp. 16–18, 25[E1]High — corrected from "frontmatter only" and de-numbered (see Drift).
q3cA skill is a packaging mechanism (deterministic, AI, or both); wrapping in a skill ≠ AI-driven.Book pp. 13–14, 20—High — entirely the book's.
q4aclaude -p composition (layered system) + recovery as a capability not a guarantee; hooks for must-run steps.Book pp. 20–24[E1]High — softened from "still works / fails only if gone" (see Drift).
q5cRule of thumb: skill (recurring methodology, main context) vs subagent (heavy/isolated) vs MCP (external); context: fork.Book pp. 26–27[E1], [E3]High.
q6bSynthesis: instruction (skill) vs integration (MCP) vs isolation (subagent); shared lazy loading; slash-commands-merged-into-skills; skills as a cross-product open standard.Book pp. 25–29 + the layer distinctions[E1], [E2], [E3], [E4]High — the one enrichment-grounded synthesis question. MCP-tool-search and the merge correct the book (see Drift).

Drift / Corrections Applied

The book is broadly current on skills, but a follow-up accuracy pass (verified directly against [E1] skills, plus [E2]–[E6]) tightened several points. The book's original wording is preserved verbatim in extracted-chapters/ and is not edited.

2026-06-15 accuracy pass. Verified against [E1] (fetched directly), [E2] MCP, [E3] subagents, [E4] commands, [E5] plugins, [E6] Agent SDK. Eight adjustments propagated across the lesson, quiz, this ledger, and the training-output mirror. The new rows below record each.
ItemBook / draft positionCurrent / correct positionLesson treatment
Skill selection (CORRECTION)An early draft said "selection is driven entirely by the frontmatter … everything below the --- plays no role."Per [E1]: Claude decides from the skill listing — primarily the description (recommended), with when_to_use appended; if description is omitted, the first paragraph of the Markdown body is used. So body text can matter for selection in the no-description case.§2, objective 2, the selection blockquote, Figure 9.A caption/aria, Part 2 of the lab, the common-pitfalls bullet, and q2 reworded to "Claude routes on the listing — primarily the description," with the when_to_use and first-paragraph nuances.
Skill-content lifecycle (COMPLETION)The book/draft says a skill's body loads "only when used," implying it's transient; §1 draft said the loaded context "goes away again."Per [E1]: once invoked, the rendered SKILL.md content enters the conversation and stays for the rest of the session (Claude doesn't re-read the file each turn) — a recurring token cost, so keep bodies lean. Auto-compaction re-attaches the most recent invocation of each skill within a budget.§1 "goes away again" replaced with "loaded conditionally … and then persists in-session — so keep the body lean"; §2 stage 2 now states persistence + the compaction re-attachment note; objective 2 updated.
Enforcement / fallback (SOFTENING)Book/draft: the skill "enforces" the methodology; "ALWAYS use the script means the agent runs it"; the broken-path skill "still works"; the agent "recovers"; "fails only if the artifact is gone."Per [E1]: a skill provides instructions Claude follows, not deterministic enforcement; if a skill stops influencing behavior, "use hooks to enforce behavior deterministically." Recovery from a moved/failed script is agent judgment — a capability, not a guarantee.§1/§3 "enforces"→"guides/expresses"; §4 + Figure 9.B + the §4 analogy + Part 4 + q4 + success-checklist reworded to "recovery possible, not guaranteed," with an explicit "use a hook for steps that must run every time."
Token / scale numbers (SOFTENING — not docs facts)Book gives "~100–200 tokens per skill"; an enrichment source gave "17 official skills ≈ 1,700 tokens."These are illustrative/third-party, not official Claude Code behavior; the listing budget is configurable per [E1].All exact token counts removed from the four artifacts; replaced with qualitative "low, fixed upfront cost." The book's figure is recorded here, not reproduced as fact.
Launch dates (SOFTENING — background, not behavior)Book dates skills to "October 2025"; an open-standard release is dated "December 2025."These are announcement/ecosystem facts, not Claude Code behavior; per the project soft-wording rule and source-boundary discipline.Hard month/year strings removed from the four artifacts; the currency note says skills were "introduced in Claude Code during 2025 (the book dates this to late 2025)" and are "a cross-product open standard at agentskills.io," explicitly labelled background. (The extract retains the book's "October 2025.")
Bundled-script path (CORRECTION)Book references the script with a brittle relative path: bash skills/git-pushing/scripts/smart_commit.sh.Per [E1], the portable form is ${CLAUDE_SKILL_DIR} — "the directory containing the skill's SKILL.md… use this … to reference scripts or files bundled with the skill, regardless of the current working directory," resolving correctly at personal/project/plugin scope.§1, §3, and the lab's SKILL.md body use bash ${CLAUDE_SKILL_DIR}/scripts/…, with a one-line explanation; the book's relative form is flagged as brittle.
MCP context efficiency (CORRECTION)The book's Table 9.1 marks MCP "tools loaded at session start" / "context efficiency: low," contrasted against skills' lazy loading.Per [E2], MCP Tool Search is enabled by default in normal supported conditions and defers MCP tool definitions — so MCP is far more context-efficient than the book's table implies; progressive/lazy loading is shared across skills and MCP, not skills-only.§5 prose and the consolidated table state MCP defers tool defs by default (tool search); q6 carries the correction. The deeper point (skills carry instructions, MCP carries tools) is kept.
Slash commands merged into skills (CLARIFICATION)The book's Table 9.1 treats "Slash commands" as a distinct fourth primitive.Per [E1]/[E4]: custom commands have been merged into skills — .claude/commands/x.md and .claude/skills/x/SKILL.md both create /x and behave the same. "Slash commands" really names the user-invoked surface; custom ones are skills (built-ins like /clear remain separate).§5 explains the merge (tying back to Chapter 3); the table footnote-frames slash commands as the user-invoked surface.
context: fork returns a summary (COMPLETION)The book introduces context: fork / agent as isolation.Per [E1]: the skill content becomes the subagent's prompt, it doesn't see conversation history, and results are summarized and returned to the main conversation.§4's context: fork bullet states it returns a summary (Chapter 7 isolation).
Source boundary (FRAMING)n/aEngineering posts ([E8]/[E9]), the open standard ([E7]), LangChain ([E10]), and the community marketplace ([E11]) are enrichment, not official Claude Code behavior.The lesson cites them only as further-reading/context; the currency note and the DeepAgents/marketplace mentions are labelled background; Claude Code behavior rests on [E1]–[E6].
allowed-tools is a grant (CARRIED FROM CH3)n/a — consistent with Chapter 3.Per [E1]: allowed-tools grants listed tools without per-use approval while the skill is active (does not restrict); disallowed-tools restricts.§4's "two permissions" note frames the auto-approval as an allowed-tools-style grant (Chapter 3).
Canonical docs host (NOTE)n/aThe canonical host is code.claude.com; docs.claude.com mirrors.The lesson and further reading cite code.claude.com / platform.claude.com throughout.

Extraction caveat (image-only PDF, summarized prose)

source-pdfs/09-chapter-09.pdf is an image-only PDF — no text layer (the image-only check printed 0). The source-of-truth extracted-chapters/09-chapter-09.md was produced by rendering each of the 30 pages to PNG at 150 DPI (PyMuPDF / fitz) into work/09-chapter-09-pages/ and transcribing the images visually. Consequences a reviewer should know:

  • Mixed-fidelity extract. Explanatory prose is captured as faithful summaries; headings, code, commands, YAML/SKILL.md contents, file paths, key names, flags, and table cells are verbatim. Treat code/config/paths/tables as exact; treat prose as a structural summary. Re-open the page images in work/09-chapter-09-pages/ for exact sentence wording.
  • Page markers are reliable, but printed book page numbers are unknown — <!-- page N --> is the PDF page index. There is no .txt mirror.
  • The book's figures are screenshots (terminal/editor/browser captures, plus illustrations) and are not reproduced (the two lesson diagrams are original SVGs).
  • Table 9.1's first data row was partially cut at the top of page 28 in the render — only the tail of its cells was legible (Skills "…performed", MCP "…services", Subagents "…agents", Slash commands "…short calls"). The remaining eight rows are fully captured. The lesson's consolidated comparison is built from current docs ([E1]–[E4]) rather than the book's table, so this gap does not affect the lesson; cross-check the printed book if the exact first-row wording is needed.
  • Re-transcription, not OCR. PyMuPDF was used to render pages; no OCR engine was involved. Cross-check the printed book if exact wording/pagination matters.
Chapter 10: Using Claude Code Desktop

Source Ledger — Chapter 10: Using Claude Code Desktop

Primary source (the book)

  • Source PDF: source-pdfs/10-chapter-10.pdf (43 pages; page 43 is Packt back-matter promo, not chapter content).
  • Extracted source: extracted-chapters/10-chapter-10.md (visual extraction, <!-- page N --> markers; the markers are PDF-page indices, not printed book pages). There is no usable .txt for this chapter — see the Extraction caveat at the end.
  • Extraction tool: the Chapter 10 PDF is image-only (the image-only check python -c "import pypdf; print(sum(len(p.extract_text() or '') for p in pypdf.PdfReader('source-pdfs/10-chapter-10.pdf').pages))" printed 0). Extracted by rendering all 43 pages to PNG at 150 DPI with PyMuPDF (fitz) into work/10-chapter-10-pages/ and transcribing visually. Mixed-fidelity: headings, code, commands, file paths, key names, flags, and branch names are verbatim; explanatory prose is captured as faithful section-by-section summaries (to avoid reproducing a copyrighted chapter at length). Treat code/commands/paths/branch names as exact; treat prose as a structural summary, and re-open page images for exact sentence wording.
  • Book's main sections (from the extract, in order): "Introducing Claude Code desktop integration and background agents" (pp. 2–3); "Claude Code installation and operating modes: Local versus cloud" — Selecting the workspace folder (Local worktree mode) / Switching to Claude Code web (pp. 3–9); "How Git worktrees enable parallel development" (pp. 9–11); "Orchestrating parallel local and cloud agents" — run Next.js locally / coordinate local + cloud / concurrent feature dev / observe remote branch creation / process research results / worktree layout / preparing to merge (pp. 11–20); "Understanding Git Worktrees in Claude Code" — how Claude uses a worktree / multiple worktrees in parallel (pp. 20–24); "Merging parallel feature branches" — merge into project/hookhub / test before pushing / validate / finalize (pp. 24–30); "Running Claude Code in the cloud via mobile" — review the PR / verify locally (pp. 30–37); "When Parallel Agents Are Counterproductive" — Note/Pro-tip + Parallel Development Checklist (pp. 37–41); "Summary" (pp. 41–42).

Enrichment sources

The lesson silently incorporates material from the official Claude Code docs, the Anthropic blog, and Anthropic engineering/cookbook content. Per project convention, no inline > Source: / > Enrichment — … labels appear in the learner-facing lesson — the only in-lesson labelled callouts are the > Analogy — … boxes. This ledger is the single source of provenance.

Official Claude Code behavior (authoritative):

  • [E1] Anthropic docs — Desktop app — https://code.claude.com/docs/en/desktop
  • [E2] Anthropic docs — Desktop quickstart — https://code.claude.com/docs/en/desktop-quickstart
  • [E3] Anthropic docs — Worktrees (Run parallel sessions with worktrees) — https://code.claude.com/docs/en/worktrees
  • [E4] Anthropic docs — Run agents in parallel — https://code.claude.com/docs/en/agents
  • [E5] Anthropic docs — Agent View — https://code.claude.com/docs/en/agent-view
  • [E6] Anthropic docs — Claude Code on the web — https://code.claude.com/docs/en/claude-code-on-the-web
  • [E7] Anthropic docs — Remote Control — https://code.claude.com/docs/en/remote-control

Announcement / color (NOT official Claude Code behavior — clearly labelled as background):

  • [E8] Anthropic blog — Redesigning Claude Code on desktop for parallel agents — https://claude.com/blog/claude-code-desktop-redesign
  • [E9] Anthropic blog — Agent view in Claude Code — https://claude.com/blog/agent-view-in-claude-code
  • [E10] Anthropic blog — Claude Code on the web — https://claude.com/blog/claude-code-on-the-web

Concept / background (NOT official Claude Code behavior — clearly labelled as background):

  • [E11] Anthropic engineering — How we built our multi-agent research system — https://www.anthropic.com/engineering/multi-agent-research-system
  • [E12] Anthropic research — Building Effective AI Agents — https://www.anthropic.com/research/building-effective-agents
  • [E13] Anthropic cookbook — Orchestrator-workers — https://platform.claude.com/cookbook/patterns-agents-orchestrator-workers

This is the fastest-moving surface in the book — the desktop app, the cloud/web experience, and the mobile paths were redesigned and expanded through 2025–2026. The book is broadly correct on the load-bearing concepts (local vs cloud; worktree isolation; integrate-test-then-push merging; the wrong-starting-branch failure mode all hold), but several specifics had drifted, firmed up, or — in the case of the book's "a cloud session runs without your MCP/hooks/output styles" gotcha — were too broad and have been corrected (a cloud session is a fresh clone, so repo-committed config travels; only user-local config doesn't — see Drift #9). All Claude Code behavior was verified against [E1]–[E7] (a 2026-06-16 re-audit fetched [E1] desktop, [E3] worktrees, [E6] Claude Code on the web, plus github-actions and remote-control directly — see the dated note in the Drift table). Source-boundary discipline: Claude Code behavior claims rest on [E1]–[E7]; blogs [E8]–[E10] are announcement/color; engineering/research/cookbook ([E11]–[E13]) are concept/background. The ~order-of-magnitude token figures from the multi-agent research system are treated as "as reported," NOT as Claude Code behavior.

Pedagogical enrichment by the training author

Not from the book and not from the docs — written for this training, inventoried here for separate audit.

  • Newcomer preface (## Before we start — desktop app, "local vs cloud," branches, worktrees, and merging). Defines the desktop app vs the terminal, local vs cloud / background agents, a branch (recap), a worktree (one-line, forward-pointing to §3), merging + a pull request (recap from Chapter 5), and parallel/orchestration (bridge from Chapters 5–7). Grounded in [E1]–[E3] and Chapters 5/6/7 continuity.
  • Per-section analogies. Seven > Analogy — … callouts, one per numbered section: §1 the same car, now with a dashboard; §2 your own workshop vs a contractor's shop; §3 separate workbenches, one shared stockroom; §4 a head chef running three stations; §5 a dress rehearsal before opening night; §6 checking on the contractor from the road; §7 opening every lane at the supermarket.
  • Whole-chapter analogy (## The whole chapter in one image — the workshop with a satellite shop). A sustained workshop-plus-satellite-shop analogy threading all seven sections (dashboard over the bench → two places to work → separate benches, one stockroom → fire the stations but check the base → dress rehearsal before opening night → don't open every lane).
  • Three SVG diagrams (the book's figures are screenshots and are not reproduced):
  • Figure 10.A — local vs cloud operating modes side by side (one engine → two execution environments; local = your disk + full config; cloud = clone-from-GitHub sandbox, default env, commits + PR, persists, scales).
  • Figure 10.B — the worktree layout (one repository / .git object store → three working directories on three branches: main on project/hookhub untouched, two worktrees on vigilant-fiestel / zealous-jemison → merge back into project/hookhub).
  • Figure 10.C — the integration-branch merge (three feature branches → temporary project/hookhub-merge integration branch where the CSS conflict is resolved → test locally :3002 → push to project/hookhub; both the resolution and the push human-gated).
  • Each figcaption explicitly notes it is "Pedagogical diagram by this training, not from the book."
  • Conceptual activity — "Split a real feature set into parallel and sequential work." Ten-minute, individual, no-setup exercise practising the §4/§7 judgment (independent vs dependent; per-agent prompts naming starting branch + file boundaries; merge order; spot the trap). Grounded in §4/§7/[E4].
  • Practical exercise — "Run a worktree-isolated parallel merge, end to end." A ~35–45 min framework-free lab in ~/cct-ch10-lab/ using only git + the Claude CLI — no npm/Next.js, no desktop app, no cloud account. Part 1: one worktree + see the isolation (a commit lands off project/hookhub); Part 2: a second parallel worktree on a different file; Part 3: integrate both on a throwaway project/hookhub-merge branch, force + resolve a real styles.css conflict, pass a trivial "test" gate, then merge to project/hookhub; Part 4: clean up the worktrees + delete the throwaway branch. Reproduces the chapter's core mechanics portably; the desktop/cloud surfaces automate these exact Git steps.

Quiz items and learning objectives remain grounded in the book chapter and the labelled enrichment; none of the analogies, diagrams, the activity, or the exercise steps are themselves assessed.

Objective → Source Mapping

Learning ObjectiveSource Section (page)EnrichmentConfidenceNotes
Explain that Claude Code lives inside the Claude desktop app (the Code tab) as a graphical front end to the same engine/config (same CLAUDE.md, MCP, hooks); describe "background agents" / cloud sessions.Book "Introducing Claude Code desktop integration and background agents" + "operating modes" intro (pp. 2–4)[E1], [E2], [E5]HighThe desktop-integration + background-agents framing is the book's; the same-engine/same-config claim and the cloud/background-session naming match [E1]/[E5]. Tab layout soft-worded (see Drift #2).
Distinguish Local worktree mode (everything on your machine; worktrees created locally) vs cloud mode (managed containerized instances on Anthropic infra; clone via GitHub, work, commit, open PRs); know the current surface naming and what differs (where code runs, repo access, tools, MCP).Book "Local versus cloud" / "Switching to Claude Code web" (pp. 3–9)[E1], [E2], [E6]HighThe two-mode distinction + the clone→work→commit→PR flow are the book's and match [E1]/[E6]. Corrected: single local/cloud toggle → Local / Remote / SSH environment picker; multi-tab layout (see Drift #2).
Explain Git worktrees in Claude Code (one repo, several directories/branches, no collisions) and the lifecycle (create worktree on a new branch → work in that dir → commit lands on the worktree branch, original untouched → merge when satisfied), plus current defaults a 2025 book may not state (origin/HEAD base; conditional cleanup).Book "How Git worktrees enable parallel development" + "Understanding Git Worktrees in Claude Code" (pp. 9–11, 20–24)[E3]HighThe worktree concept + lifecycle are the book's. Completed from [E3]: origin/HEAD base default (Drift #3), conditional cleanup (Drift #4), claude --worktree/.claude/worktrees//worktree-<name> path-and-branch + .gitignore (Drift #5).
Orchestrate parallel local + cloud agents (several independent features at once, each on its own branch) and recognize the load-bearing failure mode: an agent starting from the wrong branch (main instead of the feature branch) corrupts the merge — so specify and verify the starting branch per agent.Book "Orchestrating parallel local and cloud agents" (pp. 11–20)[E3], [E4]HighThe three-concurrent-features walkthrough and the git checkout origin/project/hookhub self-correction are the book's; §4 names two distinct starting-point mechanisms — cloud fresh-clone vs local-worktree origin/HEAD base — and does not attribute the cloud agent's wrong branch to worktree.baseRef (Drift #3). Parallel-agents landscape soft-noted (Drift #6).
Merge parallel branches safely — consolidate via a temporary integration branch, resolve conflicts, test the merged result locally before pushing — and understand there is no magic "merge all branches" command (standard Git in a worktree; delegated + advisory; human gates the push).Book "Merging parallel feature branches" (pp. 24–30)[E3], [E4]HighThe project/hookhub-merge integration-branch pattern, the CSS conflict, the test-before-push gate, and the two merge commits are all the book's. "No magic merge" is the book's own demo, sharpened; the human-in-the-loop is scoped to this delegated local-merge workflow, with Desktop Auto-fix / Auto-merge noted as the path where a PR can merge itself (Drift #7).
Judge when parallel is counterproductive (tightly coupled, shared state/ordering, very small tasks, high coordination cost, exploratory/uncertain) and apply the checklist (independent files; verify each starting branch; test the merge before pushing; clean up worktrees).Book "When Parallel Agents Are Counterproductive" + Parallel Development Checklist (pp. 37–41)[E4], [E11], [E12]High — synthesisThe anti-patterns + four-item checklist are the book's; the orchestrator-worker tradeoff is enrichment background ([E11]/[E12]), figures "as reported" (Drift #10).

Lesson Section → Source Mapping

Lesson sectionSource locationEnrichmentConfidenceNotes
Preface — desktop vs terminal; local vs cloud / background agents; branch + worktree + merge/PR recaps; parallel/orchestration bridgeConcepts across the chapter[E1], [E2], [E3]HighPedagogical framing; the Chapters 5–7 bridge is the lesson's.
"Why this chapter matters" — sequential → orchestrated/parallel; desktop + worktrees + cloud as the three enablers; parallelism-isn't-free counterweight; currency noteBook intro + summary (pp. 1–2, 41–42)[E1], [E3], [E8]HighThesis is the book's; the fastest-moving-surface currency note is the lesson's (Drift #1, #2).
§1 — Claude Code on the desktop; Code tab; same engine + same config; workspace folder; redesigned-for-parallel; background agentsBook pp. 2–4 + Figures 10.1–10.3 (screenshots)[E1], [E2], [E5], [E8]HighBook's worked surface preserved. Drift note inline: multi-tab layout + Local/Remote/SSH picker (Drift #2); "background agents" firmed up to cloud/background session (Drift #1).
§1 — analogy: the same car, now with a dashboardn/a — pedagogicaln/an/aOriginal.
§2 — Local worktree mode vs cloud mode; clone→work→commit→PR; doesn't-use-your-machine + scales; the mode-difference table; cloud config (repo-committed vs user-local)Book pp. 3–9[E1], [E2], [E6]HighThe five-step cloud flow is the book's and matches [E1]/[E6]. Corrected: the book's "defaults-only" cloud gotcha → the repo-committed-vs-user-local distinction (Drift #9); toggle → Local/Remote/SSH picker; claude.ai/code web; "cloud/background session" naming (Drift #2).
§2 — Figure 10.A (local vs cloud modes)n/a — pedagogical diagram[E1], [E6]n/aOriginal SVG; labels reflect clone-from-GitHub + default-env + persists/scales.
§2 — analogy: your own workshop vs a contractor's shopn/a — pedagogicaln/an/aOriginal.
§3 — Git worktrees; many branches at once; the lifecycle (5 steps); two-worktree layout; current defaults (origin/HEAD, conditional cleanup, CLI path/branch + .gitignore)Book pp. 9–11, 20–24[E3]HighConcept + lifecycle are the book's. Completed from [E3]: base-ref default (Drift #3), conditional cleanup (Drift #4), CLI path/branch (Drift #5).
§3 — Figure 10.B (one repo, three dirs/branches, merge back)n/a — pedagogical diagram[E3]n/aOriginal SVG; vigilant-fiestel/zealous-jemison branch names from the book's worktrees (name-ambiguity flagged in the Extraction caveat).
§3 — analogy: separate workbenches, one shared stockroomn/a — pedagogicaln/an/aOriginal.
§4 — orchestrating parallel local + cloud agents; three concurrent features; the wrong-starting-branch teaching moment (git checkout origin/project/hookhub); scale noteBook pp. 11–20[E3], [E4], [E11], [E12]HighThe walkthrough + self-correction are the book's. Decoupled the cloud agent's wrong-branch from worktree.baseRef — cloud = fresh clone of the selected repo/branch; local --worktree = origin/HEAD base (Drift #3); the orchestrator-worker scale note is labelled background (Drift #6, #10).
§4 — analogy: a head chef running three stationsn/a — pedagogicaln/an/aOriginal; encodes the "check the starting base" non-negotiable.
§5 — merging via a temporary integration branch (project/hookhub-merge); resolve CSS conflict; test (npm run dev :3002) before push; no-magic-merge framing; two human gatesBook pp. 24–30[E3], [E4]HighEntirely the book's demo; "no special merge command — standard Git in a worktree, advisory + human-gated" is the book's point sharpened (Drift #7).
§5 — Figure 10.C (integration-branch merge → test → push)n/a — pedagogical diagram[E3]n/aOriginal SVG; both the resolution and the push framed as human-gated.
§5 — analogy: a dress rehearsal before opening nightn/a — pedagogicaln/an/aOriginal.
§6 — Claude Code in the cloud via mobile; all-execution-in-the-cloud; clone/checkout/commit remotely; mirrors desktop cloud flow; @claude review this PR; verify locally; "interface changes, process doesn't"Book pp. 30–37[E6], [E7]HighThe all-cloud mobile demo + the PR + verify-locally loop are the book's. Completed: mobile = two paths — Claude Code on the web vs Remote Control (Drift #8); cloud config corrected to repo-committed-vs-user-local (Drift #9); the manual review framed as a property of this setup, not a rule (Drift #7).
§6 — analogy: checking on the contractor from the roadn/a — pedagogicaln/an/aOriginal.
§7 — when parallel is counterproductive; five anti-patterns; "start sequential" default; the four-item Parallel Development ChecklistBook pp. 37–41[E4]HighThe anti-patterns + checklist are the book's; the Chapter-6 independent-vs-dependent linkage is the lesson's.
§7 — analogy: opening every lane at the supermarketn/a — pedagogicaln/an/aOriginal.
Whole-chapter analogy: the workshop with a satellite shopn/a — pedagogical synthesisn/an/aOriginal.
Activity: Split a real feature set into parallel and sequential workn/a — pedagogical[E4]n/aOriginal; grounded in §4/§7.
Practical exercise: run a worktree-isolated parallel merge end to end (git + CLI sandbox)Book pp. 9–30 recombined into a framework-free lab[E3], [E4]High — original sequencingEvery step grounded in the book + [E3]; raw git worktree used for determinism, with claude -p as the optional agentic variant; recovery/cleanup framed per [E3].

Unsupported / Pedagogical-Only Claims

ItemJustification
Same-car-with-a-dashboard analogy (§1)Pedagogical analogy. Restates "the desktop Code tab is the same engine/config, a graphical surface."
Workshop-vs-contractor's-shop analogy (§2)Pedagogical analogy. Restates local (your bench) vs cloud (a shop across town that builds from the crate you ship — i.e. repo-committed config travels; only the tools left in your home garage / user-local config don't).
Workbenches/stockroom analogy (§3)Pedagogical analogy. Restates worktree isolation (one repo, many benches).
Head-chef-three-stations analogy (§4)Pedagogical analogy. Restates parallel-on-independent-work + the "check the starting base" rule.
Dress-rehearsal analogy (§5)Pedagogical analogy. Restates integrate-on-a-throwaway-stage, fix conflicts, rehearse (test), then go live (push).
Checking-on-the-contractor-from-the-road analogy (§6)Pedagogical analogy. Restates mobile = a window onto the cloud; same process.
Supermarket-lanes analogy (§7)Pedagogical analogy. Restates when parallelism helps vs hurts (coupled/tiny/coordination-heavy).
Workshop-with-a-satellite-shop whole-chapter analogyPedagogical synthesis. No new claims.
Figures 10.A–10.C (SVGs)Original SVGs. Visually restate local-vs-cloud, the worktree layout, and the integration-branch merge. The book's figures are screenshots and are not reproduced.
The ~/cct-ch10-lab sandbox (practical exercise)Authored for this training as a framework-free, git-only stand-in for the book's desktop/cloud/Next.js demo, so the core mechanics run anywhere without an account or npm.

Quiz Item → Source Mapping

Quiz IDAnswerItemSource locationEnrichmentConfidence
q1bDesktop Code tab = a graphical front end to the same Claude Code engine + config (CLAUDE.md, MCP, hooks carry over); a new surface, not a different tool; not cloud-only.Book pp. 2–4 (§1)[E1]High
q2aCloud (background-agent) mode vs Local worktree mode: managed Anthropic-infra instances clone from GitHub, work, commit, open a PR, persist, and scale; local runs on your machine with full config. Cloud config corrected to repo-committed travels / user-local doesn't (output styles not doc-covered); Local/Remote/SSH naming noted.Book pp. 3–9 (§2)[E1], [E6]High — cloud config corrected (Drift #9); naming firmed up (Drift #2).
q3cWhat a Git worktree is (many branches at once, each in its own dir, one repo, no re-cloning) + the lifecycle (commits land on the worktree branch, original untouched until merge); current defaults (origin/HEAD base; conditional cleanup).Book pp. 9–11, 20–24 (§3)[E3]High — completed from [E3] (see Drift #3, #4).
q4bThe wrong-starting-branch failure: the cloud agent checks out main not project/hookhub; a wrong base silently corrupts the merge → specify + verify the starting branch per agent (checklist item).Book pp. 11–20 (§4)[E3], [E4]High.
q5cThe safe merge pattern: temporary project/hookhub-merge integration branch → merge each feature in → resolve conflicts there → test locally before pushing; and no magic command — standard Git in a worktree, human-approved in this delegated local-merge workflow (with Desktop Auto-fix / Auto-merge as the PR path that can merge itself).Book pp. 24–30 (§5)[E1], [E3], [E4]High — the book's own demo, sharpened; human-gating scoped + Auto-merge noted (see Drift #7).
q6bSynthesis: parallelize only independent, well-scoped, different-file work; counterproductive for coupled/shared-state/tiny/coordination-heavy/exploratory work; start sequential by default. Mirrors the orchestrator-worker tradeoff (speed/coverage at a token cost, "as reported") and places desktop/cloud worktree agents in the wider "multiple agents" landscape (subagents, agent teams, Agent View, dynamic workflows).Book pp. 37–41 (§7) + the multi-agent lineage[E4], [E5], [E11], [E12], [E13]High — the one enrichment-grounded synthesis question. Figures "as reported," not Claude Code behavior (see Drift #10).

Drift / Corrections Applied

The book is broadly current on the load-bearing concepts (local vs cloud, worktree isolation, integrate-test-then-push, the wrong-branch failure), but this is the fastest-moving surface in the book, so accuracy passes (verified directly against [E1]–[E7]) tightened several specifics — and the 2026-06-16 re-audit corrected the book's over-broad cloud-config gotcha (repo-committed config does travel), decoupled worktree.baseRef from cloud checkout, and scoped "human-gated" to the taught workflow. The book's original wording is preserved verbatim in extracted-chapters/ and is not edited.

2026-06-15 accuracy pass. Verified against [E1] desktop, [E2] desktop-quickstart, [E3] worktrees, [E4] agents, [E5] agent view, [E6] Claude Code on the web, [E7] Remote Control. The adjustments below were propagated across the lesson, quiz, this ledger, and the training-output mirror. The rows record each. 2026-06-16 re-audit (cloud config / base-ref boundary / merge automation). A second pass re-fetched [E1] desktop, [E3] worktrees, and [E6] Claude Code on the web (plus code.claude.com/docs/en/github-actions and …/remote-control) and corrected three over-broad claims in rows #3, #7, and #9: (#9) the book's "cloud runs without your MCP/hooks/output styles" is too broad — repo-committed config travels with the clone, only user-local config doesn't, and output styles aren't doc-covered (so no hard claim); (#3) worktree.baseRef governs local worktrees and is not tied to cloud-session checkout (cloud = fresh clone) — the earlier draft's §4 link was decoupled; (#7) "human-gated" is scoped to the taught local-merge workflow, since Desktop PR monitoring documents Auto-fix and Auto-merge. Propagated across the lesson, quiz, this ledger, and the training-output mirror. The book's original wording remains untouched in extracted-chapters/.
ItemBook / draft positionCurrent / correct positionLesson treatment
1. Background-agents terminology (CLARIFICATION)Book uses "background agents / Claude Code web / remote workers" loosely as the names for cloud-run instances.All terms are still in use, but current docs lean on "cloud session" / "background session" — the naming firmed up. [E1], [E5]§1 introduces "background agent / cloud session" as interchangeable; §2's drift note states the docs lean on "cloud session"/"background session"; the currency note flags the firming-up.
2. Local-vs-cloud toggle / desktop layout (CORRECTION)Book shows a single local/cloud toggle (a cloud-icon default) and a single desktop surface.As of writing the desktop surface uses an explicit Local / Remote / SSH environment picker at session start (Remote = the cloud option), and the desktop app organizes work into more than one tab (a chat surface, a longer-running-work surface, and the Code tab). [E1], [E2]§1 + §2 drift notes state the multi-tab layout and the Local/Remote/SSH picker; the lesson teaches the stable local-vs-cloud concept and soft-words the exact picker/tab labels (verify in [E1]/[E2]).
3. Worktree base ref (and its boundary vs cloud checkout) (COMPLETION + CORRECTION)Book's walkthrough implies worktrees start from the current/feature branch the agent is on. An earlier draft of this lesson also tied the cloud agent's wrong-branch incident to the origin/HEAD worktree default.As of writing local worktrees branch from origin/HEAD (the repository's remote default) by default — so a fresh worktree may not contain local unpushed commits; opt into local HEAD with worktree.baseRef: "head" [E3]. Critically, the docs do NOT tie worktree.baseRef to cloud-session checkout: a cloud session starts from a fresh clone of the selected repo/branch context — a separate mechanism [E6]. So the cloud hero agent's checkout of main is a cloud-clone/branch-selection matter, not a worktree.baseRef effect.§3 scopes the origin/HEAD default explicitly to local --worktree; §4 and q4 decouple the cloud agent's wrong-branch incident from worktree.baseRef (naming the two distinct mechanisms: cloud fresh-clone vs local-worktree base-ref); q3 + the common-pitfalls bullet carry the local-worktree default.
4. Worktree cleanup (COMPLETION / SOFTENING)Book does not state cleanup behavior; a reader could assume worktrees vanish on their own.Cleanup is conditional, not automatic: a clean unnamed session is removed on exit; a named session, or one with uncommitted changes or new commits, prompts; non-interactive (-p) runs are not auto-removed. [E3]§3 states the conditional rule; §7 checklist item 4 ("clean up worktree directories after merging") is framed as a real step; Part 4 of the lab runs git worktree remove; q3 + a common-pitfalls bullet carry it.
5. Worktree path / branch (surface) (COMPLETION)Book screenshot shows a worktree location like ~/.claude-worktrees/....From the CLI, claude --worktree <name> creates a worktree at .claude/worktrees/<name>/ on branch worktree-<name>; the desktop app auto-creates a worktree per session and manages its path — so the exact storage path differs by surface and version. Add .claude/worktrees/ to .gitignore. [E3]§3 gives the CLI path/branch as "as of writing," explicitly notes the desktop path differs, and recommends the .gitignore entry; the exact path is soft-worded.
6. Parallel-agents landscape (COMPLETION)Book presents parallel local + cloud worktree agents as the way to run multiple agents."Multiple agents" is not a fixed set — it spans in-session subagents (Ch7), experimental agent teams (env-gated CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS), Agent View / background sessions (claude agents), dynamic workflows, the /batch skill, multiple terminals, and desktop parallel sessions. [E4], [E5]§4's scale note + Further reading + q6 place desktop/cloud worktree agents as one point in the wider landscape, not the only mechanism.
7. No magic merge — and "human-gated" is scoped, not absolute (CLARIFICATION + SOFTENING)Book asks Claude to "merge all the commits to project/hookhub," which can read as a built-in consolidation feature. An earlier draft also stated the merge "is advisory and human-gated, not autonomous" as a blanket property.There is no special "merge all branches" command — Claude runs standard Git (git checkout, git merge, conflict resolution, a test run) in a worktree because you delegated it; in the delegated local-merge workflow taught here a human approves the conflict resolution and the push (matching the book's own project/hookhub-merge demo). **But that human-in-the-loop is a property of this workflow, not a universal rule: per [E1], the Desktop app's PR monitoring offers Auto-fix (Claude reads failing CI output and iterates to fix checks) and Auto-merge** (Claude squash-merges once all checks pass — requires auto-merge enabled in the GitHub repository settings). [E1], [E3], [E4]§5 keeps "there is no magic merge," scopes the two human approvals to "the workflow taught here," and adds a paragraph on Desktop Auto-fix/Auto-merge; §6 reworded ("in this demo the review stays manual … a property of this setup, not a rule"); q5 (option + explanation) carry the Auto-fix/Auto-merge nuance; Figure 10.C + the §5 analogy depict the taught (human-gated) flow; a common-pitfalls bullet keeps "don't expect a merge-all button."
8. Mobile = two distinct paths (COMPLETION)Book demos an all-cloud mobile flow (repo cloned/checked-out/committed remotely from the phone).There are two distinct current models: Claude Code on the web (claude.ai/code, research preview — cloud sessions reachable from any browser/phone, plus an iOS app) — the all-cloud model the book shows; and Remote Control — connects the Claude mobile app to a session running locally on your own machine (so local files/config are reachable). [E6], [E7]§6 teaches the book's cloud/web path and soft-notes Remote Control as the distinct local-from-phone model in a drift note + Further reading; the lesson does not conflate them.
9. Cloud session config (CORRECTION — book overbroad; NOT confirmed)Book states a default cloud/background session runs without your custom MCP servers, hooks, or output styles unless configured — and an earlier draft of this lesson repeated that as a "clean default environment / confirmed" gotcha.Per [E6] (Claude Code on the web) and [E1]: a cloud session is a fresh clone of your repository, so anything committed to the repo IS available — repo CLAUDE.md, .claude/settings.json hooks, .mcp.json MCP servers, .claude/rules/, .claude/skills//.claude/agents//.claude/commands/, and plugins declared in .claude/settings.json. What does not carry over is config that lives only on your machine: user ~/.claude/CLAUDE.md, user-local skills/agents/commands, plugins enabled only in user settings, and MCP servers added with claude mcp add (those write to local user config, not the repo). Docs describe per-environment settings, a setup script, and a SessionStart hook for cloud-only setup. The docs do NOT explicitly cover output styles in cloud sessions, so no hard claim is made either way. The book's blanket "runs without your MCP/hooks/output styles" is therefore too broad and is explicitly NOT treated as confirmed.§2's table row + paragraph rewritten to the repo-committed-vs-user-local distinction; Figure 10.A labels/aria updated ("repo-committed config travels … user-local does not"); the §2 "contractor's shop" analogy reframed (build from the crate you ship = repo config); §6's parenthetical corrected (repo config travels; the demo repo just has little committed config); the common-pitfalls bullet reworded ("Assuming the cloud mirrors your machine"); q2's explanation rewritten. Output styles soft-worded ("don't assume either way").
10. Multi-agent token figures (SOFTENING — background, not behavior)n/a (book does not cite these; the lesson adds them as enrichment context).The multi-agent research write-up reports the orchestrator-worker system beating a single agent on a research eval **while using far more tokens (roughly an order of magnitude, as reported)** — an enrichment/background fact, not Claude Code behavior or a documented mechanic. [E11], [E12], [E13]§4's scale note + q6's explanation present the tradeoff with explicit "as reported / reported background, not Claude Code mechanics" wording; no hardcoded multipliers presented as fact.
Source boundary (FRAMING)n/aBlogs [E8]–[E10] are announcement/color; engineering/research/cookbook [E11]–[E13] are concept/background; Claude Code behavior rests on [E1]–[E7].The lesson cites [E8]–[E13] only as further-reading/context (labelled "as of writing / research preview" and "reported background"); behavior claims rest on the docs.
Canonical docs host (NOTE)n/aThe canonical host is code.claude.com; docs.claude.com mirrors.The lesson and Further reading cite code.claude.com / claude.com/blog / platform.claude.com throughout.

Extraction caveat (image-only PDF, summarized prose)

source-pdfs/10-chapter-10.pdf is an image-only PDF — no text layer (the image-only check printed 0). The source-of-truth extracted-chapters/10-chapter-10.md was produced by rendering each of the 43 pages to PNG at 150 DPI (PyMuPDF / fitz) into work/10-chapter-10-pages/ and transcribing the images visually. Consequences a reviewer should know:

  • Mixed-fidelity extract. Explanatory prose is captured as faithful summaries; headings, code, commands, file paths, key names, flags, and branch names are verbatim. Treat code/commands/paths/branch names as exact; treat prose as a structural summary. Re-open the page images in work/10-chapter-10-pages/ for exact sentence wording.
  • Page markers are reliable, but printed book page numbers are unknown — <!-- page N --> is the PDF page index. There is no .txt mirror.
  • Page 43 is Packt back-matter promo (other-titles / "leave a review" marketing), not chapter content — ignore it for sourcing.
  • The book's figures are screenshots (desktop/terminal/browser/GitHub/mobile captures) and are not reproduced (the three lesson diagrams are original SVGs).
  • needs review — page-24 figure number. The printed figure number on PDF page 24 rendered ambiguously as "Figure 10.2x"; inferred to be 10.24 because the following page carries 10.25. Flagged in the extract and mirrored in work/open-issues.md. Cross-check the printed book if the exact figure number matters.
  • needs review — worktree name ambiguity. The first worktree's branch name appears in the source screenshots as both vigilant-fiestel and vigilant-fieste1 (an l/1 OCR/visual ambiguity at small render size; the extract also shows the looser early rendering "vigilant feistal"). The lesson and diagrams standardize on vigilant-fiestel for consistency; the alternate vigilant-fieste1 is recorded here as the source ambiguity. The exact on-screen string is not load-bearing for any lesson claim (it's an auto-generated friendly name); cross-check the page images if a citation needs the literal string.
  • Re-transcription, not OCR. PyMuPDF was used to render pages; no OCR engine was involved. Cross-check the printed book if exact wording/pagination matters.
Chapter 11: Understanding Deep Agents

Source Ledger — Chapter 11: Understanding Deep Agents

Primary source (the book)

  • Source PDF: source-pdfs/11-chapter-11.pdf (20 pages; page 20 is Packt back-matter promo, not chapter content). This is the final chapter (Part 3).
  • Extracted source: extracted-chapters/11-chapter-11.md (visual extraction, <!-- page N --> markers; the markers are PDF-page indices, not printed book pages). There is no usable .txt for this chapter — see the Extraction caveat at the end.
  • Extraction tool: the Chapter 11 PDF is image-only (the image-only check python -c "import pypdf; print(sum(len(p.extract_text() or '') for p in pypdf.PdfReader('source-pdfs/11-chapter-11.pdf').pages))" printed 0). Extracted by rendering all 20 pages to PNG at 150 DPI with PyMuPDF (fitz) into work/11-chapter-11-pages/ and transcribing visually. Mixed-fidelity: headings, code, commands, file paths, key names, flags, tool names, and the LangChain base-prompt excerpt are verbatim; explanatory prose is captured as faithful section-by-section summaries (to avoid reproducing a copyrighted chapter at length). Treat code/commands/paths/tool-names as exact; treat prose as a structural summary, and re-open page images for exact sentence wording.
  • Book's main sections (from the extract, in order): "Agent taxonomy in production systems" (pp. 1–3; the ReAct reason→act→observe loop, hybrid RAG, Figure 11.1 taxonomy, Figures 11.2/11.3 flowcharts); "Shallow agents and their limitations" (pp. 3–5; function calling → context grows → context rot as bloat/contradiction/pollution; Figure 11.4) — within it "Coding agents" (pp. 5–6; Claude Code/Devin/Cursor/Gemini CLI) and "Innovation at the application layer" (pp. 6–7; the Agent Harness Note); "What makes an agent deep?" (pp. 7–8; the four building blocks; Figure 11.5 adapted from the LangChain blog); "Planning tool in Deep Agents" (pp. 8–9; explicit dynamic to-do list; TodoWrite/TodoRead with {todos: Todo[]}); "Subagents and hierarchical delegation" (pp. 9–11; isolated context, returns only the final result; Figures 11.6/11.7); "Filesystem access in Deep Agents" (pp. 12–14; Read/Write/Edit/Glob/Grep/NotebookEdit and the LangChain ls/read_file/write_file/edit_file/glob/grep interface; the three-box model Figure 11.9); "The filesystem as a context engine" (pp. 14–15; write-out + select-back); "System prompt" (pp. 15–18; a reasoning framework not a flowchart; heuristic principles; language efficiency; the LangChain DeepAgents base_prompt.md excerpt, MIT-licensed); "Summary" (p. 19).

Enrichment sources

The lesson silently incorporates material from the official Claude Code docs, the LangChain DeepAgents materials, and Anthropic engineering/cookbook content. Per project convention, no inline > Source: / > Enrichment — … labels appear in the learner-facing lesson — the only in-lesson labelled callouts are the > Analogy — … boxes. This ledger is the single source of provenance.

Claude Code behavior (authoritative — official docs):

  • [E9] Anthropic docs — Subagents — https://code.claude.com/docs/en/sub-agents
  • [E10] Anthropic docs — Tools reference — https://code.claude.com/docs/en/tools-reference
  • [E11] Anthropic docs — Permission modes — https://code.claude.com/docs/en/permission-modes
  • [E12] Anthropic docs — Memory — https://code.claude.com/docs/en/memory
  • [E15] Anthropic docs — Commands (/tasks = background tasks; verified in the 2026-06-16 re-audit) — https://code.claude.com/docs/en/commands
  • [E16] Anthropic docs — Output styles (output styles modify the system prompt) — https://code.claude.com/docs/en/output-styles
  • [E17] Anthropic docs — Agent SDK: modifying system prompts (the separate system-prompt API surface) — https://code.claude.com/docs/en/agent-sdk/modifying-system-prompts

LangChain DeepAgents (authoritative for the FRAMEWORK's design + the "deep agent" term — NOT Claude Code behavior):

  • [E1] LangChain blog — Deep Agents — https://www.langchain.com/blog/deep-agents
  • [E2] LangChain — deepagents docs (overview) — https://docs.langchain.com/oss/python/deepagents/overview
  • [E3] LangChain — deepagents repo — https://github.com/langchain-ai/deepagents
  • [E4] LangChain blog — How agents can use filesystems for context engineering — https://blog.langchain.com/how-agents-can-use-filesystems-for-context-engineering/

Concept / background (NOT Claude Code behavior — clearly labelled as background):

  • [E5] Anthropic — Building Effective AI Agents — https://www.anthropic.com/research/building-effective-agents
  • [E6] Anthropic engineering — Effective context engineering for AI agents — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
  • [E7] Anthropic engineering — How we built our multi-agent research system — https://www.anthropic.com/engineering/multi-agent-research-system
  • [E8] Anthropic cookbook — Orchestrator-workers — https://platform.claude.com/cookbook/patterns-agents-orchestrator-workers
  • [E13] ReAct: Synergizing Reasoning and Acting in Language Models (arXiv) — https://arxiv.org/abs/2210.03629
  • [E14] GPT Researcher (open-source deep-research agent) — https://github.com/assafelovic/gpt-researcher

This chapter is conceptual — it teaches an architecture (the "deep agent" four-pillar pattern) rather than a Claude Code surface to operate, so most of the load-bearing claims are about the framework idea and only a handful are Claude Code behavior. The book is broadly current on the concept: the taxonomy, context rot, the four building blocks, and the filesystem-as-context-engine principle all hold. The specifics that drifted are (1) the terminology — "deep agent" is a community/LangChain articulation, not an Anthropic/Claude Code label (the book itself acknowledges LangChain articulated it); and (2) the planning tool names — the book's TodoWrite/TodoRead are the legacy surface, replaced by the Task* family ([E10]). All Claude Code behavior was verified against [E9]–[E12]. Source-boundary discipline: Claude Code behavior claims rest on [E9]–[E12]; the LangChain materials [E1]–[E4] are authoritative for the framework's design and the "deep agent" term but not for Claude Code behavior; Anthropic engineering/research/cookbook [E5]–[E8] are concept/background, and the orchestrator-worker token/eval figures (≈4×/≈15×/≈90.2% from [E7]) are treated as "as reported," NOT as Claude Code behavior; ReAct [E13] is the academic foundation.

Pedagogical enrichment by the training author

Not from the book and not from the docs — written for this training, inventoried here for separate audit.

  • Newcomer preface (## Before we start — agents, ReAct, "long-horizon", harnesses, and the four pillars). Recaps what an agent is, the ReAct loop, shallow vs. deep, "long-horizon" + context rot, the agent harness, and the four pillars (one line each). States up front that "deep agent" is a community/LangChain term, not an Anthropic/Claude Code label (Anthropic more commonly discusses "long-running / long-horizon" agentic work, context engineering, and agents/workflows rather than defining "deep agent" as an official term). Grounded in [E1], [E6], [E13] and book continuity (Chapters 1, 7, 9).
  • Per-section analogies. Seven > Analogy — … callouts, one per numbered section: §1 vehicles on the road (bicycle vs. long-haul truck vs. fitted-out workshop truck); §2 a desk that's never cleared; §3 what makes an expedition, not a walk; §4 the whiteboard the surgeon keeps glancing at; §5 the general contractor and the trades; §6 the detective's case room, not their pockets; §7 the constitution, not the to-do list.
  • Whole-chapter / whole-book analogy (## The whole chapter in one image — the expedition, and the whole book). A sustained expedition analogy threading all seven sections, then a book capstone mapping all 11 chapters back to the four pillars / context engineering. No new claims.
  • Three SVG diagrams (the book's figures are taxonomy/flowchart/architecture diagrams + terminal screenshots and are not reproduced):
  • Figure 11.A — the agent taxonomy as nested regions (Agents in production ⊃ shallow [ReAct loop] and deep [long-horizon]; deep ⊃ deep-research agents and coding agents; the harness as the wrapping application layer).
  • Figure 11.B — the four pillars as four columns holding a roof labeled "long-horizon execution," each mapped to its Claude Code surface (system prompt + CLAUDE.md; Task*/legacy TodoWrite; the Agent tool; Read/Write/Edit/Glob/Grep), all resting on a "context engineering" foundation; three of the four flagged as context-management moves.
  • Figure 11.C — the filesystem context-engine three-box model (all-available ⊃ selected vs. required), contrasting "without a filesystem" (everything dumped → overflow → rot) with "with a filesystem" (write state out to disk; glob/grep select a small set that covers required).
  • Each figcaption explicitly notes it is "Pedagogical diagram by this training, not from the book."
  • Conceptual activity — "Find the four pillars in a tool you use." Ten-minute, individual, no-setup exercise practising the §3–§7 lens (locate each pillar in a deep agent you use; tie each to a failure it prevents; spot the three context-management moves; name the loose language you'd correct). Grounded in §2–§7.
  • Practical exercise — "Watch the four pillars run in Claude Code." A ~35–45 min framework-free lab in ~/cct-ch11-lab/ using only Claude Code + git — no npm, no LangChain install, no API keys. Part 1: a deliberately multi-step task → watch the Task* to-do list update (legacy TodoWrite flagged). Part 2: delegate exploration to a subagent → it returns a summary from an isolated context (/context before/after). Part 3: write state to NOTES.md, then retrieve selectively with grep/glob. Part 4: add a CLAUDE.md heuristic and watch behavior shift (Pillar 1). Optional read-only stretch: open the LangChain DeepAgents base_prompt.md to compare. Reproduces the chapter's concepts as something the learner can see, portably.

Quiz items and learning objectives remain grounded in the book chapter and the labelled enrichment; none of the analogies, diagrams, the activity, or the exercise steps are themselves assessed.

Objective → Source Mapping

Learning ObjectiveSource Section (page)EnrichmentConfidenceNotes
Place coding agents within the production agent taxonomy — the broad domain of agents (hybrid RAG, agentic apps) divides into shallow (the ReAct loop) and deep agents, deep agents split into deep-research and coding agents (Claude Code, Cursor, Devin, Gemini CLI) — and explain why the application layer (the "agent harness") is where most current innovation happens.Book "Agent taxonomy in production systems" + "Coding agents" + "Innovation at the application layer" (pp. 1–7)[E1], [E5], [E13], [E14]HighThe taxonomy, the harness Note, and the "incremental model / fast application layer" framing are all the book's; ReAct grounded in [E13]; GPT Researcher in [E14]; the harness idea echoes [E1].
Explain the shallow-agent limitation — each ReAct iteration injects the tool result back into the prompt, so context grows until it suffers context rot (bloat, contradiction, pollution), degrading quality and raising cost/latency — and define "deep": complex, long-running (long-horizon) tasks done with quality/reliability, which reduces to smart context management.Book "Shallow agents and their limitations" + "What makes an agent deep?" intro (pp. 3–8)[E6], [E13]HighThe function-calling → context-rot mechanism and the "context management is the whole game" thesis are the book's; the attention-budget framing echoes [E6].
Name the four building blocks (detailed system prompt, planning tool, subagents, filesystem) and recognize that "deep agent" is a community/LangChain-articulated term, not an official Anthropic/Claude Code label (Anthropic more commonly discusses "long-running / long-horizon" agentic work, context engineering, and agents/workflows rather than defining "deep agent" as an official term); map each block onto Claude Code and the LangChain DeepAgents harness.Book "What makes an agent deep?" (pp. 7–8; Figure 11.5)[E1], [E2], [E3]HighThe four-block list is the book's (and Figure 11.5 is adapted from the LangChain blog). Terminology clarified: "deep agent" labeled a community/LangChain term throughout — see Drift #1. The framework mapping draws on [E1]–[E3].
Explain the planning block — an explicit, dynamic to-do list (pending / in-progress / completed) the agent rewrites as it works, whose real job is context management (re-orienting the agent), not computation — and know the current Claude Code surface (Task* — TaskCreate/TaskList/TaskGet/TaskUpdate), with the book's TodoWrite/TodoRead now legacy (disabled by default), distinct from read-only plan mode (Chapter 6).Book "Planning tool in Deep Agents" (pp. 8–9)[E1], [E10], [E11]HighThe explicit-dynamic-to-do-list concept ("almost a no-op" per [E1]) is the book's and current. Corrected: TodoWrite/TodoRead → the Task* family per [E10] — see Drift #2; plan-mode distinction added from [E11].
Explain subagents / hierarchical delegation — an orchestrator delegates a scoped task to a specialized subagent with its own system prompt, tools, and isolated context window; the subagent works independently and returns only its final result, keeping the main context lean and enabling parallelism — and connect it to the Agent tool (formerly Task), Chapter 7, and orchestrator-workers.Book "Subagents and hierarchical delegation" (pp. 9–11; Figures 11.6/11.7)[E7], [E8], [E9], [E10]HighThe isolated-context / returns-only-final-result delegation and the Claude Code exploration-subagent example are the book's. Completed: the Agent tool (formerly Task) from [E9]/[E10] — see Drift #4; orchestrator-workers from [E7]/[E8] (figures "as reported," Drift #5).
Explain the filesystem block — writing intermediate state to disk plus selective retrieval (glob/grep) — as the mechanism behind "precise context selection"; ground it in the attention-budget / three-box model (all-available ⊃ selected vs. required), Claude Code's file tools (Read/Write/Edit/Glob/Grep/NotebookEdit) and memory (CLAUDE.md + auto-memory) — and recognize "the filesystem as a context engine" is an engineering principle, not a documented Claude Code feature name.Book "Filesystem access in Deep Agents" + "The filesystem as a context engine" (pp. 12–15; Figures 11.8/11.9)[E4], [E6], [E10], [E12]HighThe file-tools list, the LangChain ls/read_file/… interface, and the three-box model are the book's (Figure 11.9 is sourced from [E4]). Framed: "context engine" labeled a principle ([E6]/[E4]) not a feature — see Drift #3; file tools per [E10], memory per [E12].

Lesson Section → Source Mapping

Lesson sectionSource locationEnrichmentConfidenceNotes
Preface — agent recap; ReAct; shallow vs. deep; "long-horizon" + context rot; agent harness; the four pillars; "deep agent" is a community termConcepts across the chapter (pp. 1–8)[E1], [E6], [E13]HighPedagogical framing; the "deep agent is a community/LangChain term" note states Drift #1 up front.
"Why this chapter matters" — capstone framing (the architecture under every earlier chapter); the four-pillar pattern; the sources-and-currency noteBook intro + summary (pp. 1, 19)[E1], [E6], [E10]HighThe capstone thesis is the lesson's synthesis; the currency note flags Drift #1, #2, #3.
§1 — the agent taxonomy; domain of agents / hybrid RAG; the ReAct loop; shallow vs. deep; deep-research vs. coding agents; innovation at the application layer / agent harnessBook pp. 1–7 + Figures 11.1–11.3 (diagrams)[E1], [E5], [E13], [E14]HighBook's taxonomy preserved; ReAct [E13]; GPT Researcher [E14]; harness Note [E1].
§1 — Figure 11.A (taxonomy as nested regions)n/a — pedagogical diagram[E1], [E13]n/aOriginal SVG; the book's Figure 11.1 is a nested-boxes diagram, not reproduced.
§1 — analogy: vehicles on the roadn/a — pedagogicaln/an/aOriginal.
§2 — shallow agents hit a wall; function calling → result injected back → context grows → context rot (bloat/contradiction/pollution); cost+latency; long-running vs. one-shot tasksBook pp. 3–5 + Figure 11.4 (diagram)[E6], [E13]HighEntirely the book's mechanism; attention-budget framing echoes [E6].
§2 — analogy: a desk that's never clearedn/a — pedagogicaln/an/aOriginal.
§3 — what makes an agent "deep"; no strict definition; complex/long-running with quality+reliability = smart context management; the four building blocks; three-of-four are context-management movesBook pp. 7–8 + Figure 11.5 (adapted from [E1])[E1]HighThe four-block list is the book's (Figure 11.5 adapted from the LangChain blog); "deep agent is LangChain's term" stated (Drift #1).
§3 — Figure 11.B (four pillars as columns over "long-horizon execution")n/a — pedagogical diagram[E1]n/aOriginal SVG; each pillar mapped to its Claude Code surface.
§3 — analogy: what makes an expedition, not a walkn/a — pedagogicaln/an/aOriginal; seeds the closing whole-chapter analogy.
§4 — explicit planning via a dynamic to-do list; pending/in-progress/completed; "almost a no-op" / context management; TodoWrite/TodoRead {todos: Todo[]} → corrected to Task*; distinct from plan modeBook pp. 8–9[E1], [E10], [E11]HighConcept + "almost a no-op" from the book/[E1]. Corrected to the Task* family (Drift #2); LangChain write_todos noted; plan-mode distinction from [E11].
§4 — analogy: the whiteboard the surgeon keeps glancing atn/a — pedagogicaln/an/aOriginal; encodes "almost a no-op, but re-orients."
§5 — subagents / hierarchical delegation; own system prompt/description/tools; isolated context; returns only the final result; keeps orchestrator lean + enables parallelism; the Agent tool; orchestrator-workersBook pp. 9–11 + Figures 11.6/11.7 (diagram + screenshot)[E7], [E8], [E9], [E10]HighThe delegation mechanics + the Claude Code exploration example are the book's. Completed: Agent tool (formerly Task) (Drift #4); orchestrator-workers + "as reported" figures (Drift #5).
§5 — analogy: the general contractor and the tradesn/a — pedagogicaln/an/aOriginal; mirrors the book's craftsman/house analogy.
§6 — filesystem access; Read/Write/Edit/Glob/Grep/NotebookEdit; LangChain ls/read_file/…; the three-box model + failure modes; write-out / select-back; attention budget; memory (CLAUDE.md + auto-memory)Book pp. 12–15 + Figures 11.8/11.9 (screenshot + diagram from [E4])[E4], [E6], [E10], [E12]HighFile tools + interface + three-box model are the book's; "context engine" framed as a principle ([E6]/[E4], Drift #3); memory from [E12].
§6 — Figure 11.C (three-box model, with/without a filesystem)n/a — pedagogical diagram[E4], [E6]n/aOriginal SVG; the book's Figure 11.9 is sourced from [E4] and is not reproduced.
§6 — analogy: the detective's case room, not their pocketsn/a — pedagogicaln/an/aOriginal.
§7 — the detailed system prompt as cognitive baseline; hundreds of lines; reasoning framework not flowchart; heuristic principles; language efficiency; the LangChain DeepAgents base_prompt.md excerpt (MIT); Claude Code's system prompt + CLAUDE.md + output stylesBook pp. 15–18[E1], [E2], [E3], [E12]HighEntirely the book's section; the base_prompt.md excerpt is verbatim from [E3] (MIT); the Claude Code mapping (CLAUDE.md, Ch 8 output styles) is the lesson's continuity.
§7 — analogy: the constitution, not the to-do listn/a — pedagogicaln/an/aOriginal.
Whole-chapter / whole-book analogy: the expedition, and the whole bookn/a — pedagogical synthesisn/an/aOriginal; capstone mapping all 11 chapters to the four pillars / context engineering.
Activity: Find the four pillars in a tool you usen/a — pedagogicaln/an/aOriginal; grounded in §3–§7.
Practical exercise: Watch the four pillars run in Claude Code (~/cct-ch11-lab/, Claude Code + git only)Book pp. 8–18 recombined into a framework-free lab[E3], [E9], [E10], [E12]High — original sequencingEach part demonstrates one pillar with real Claude Code surfaces (Task* to-do list, the Agent subagent, Grep/Glob, CLAUDE.md); the optional stretch reads the [E3] base_prompt.md.

Unsupported / Pedagogical-Only Claims

ItemJustification
Vehicles-on-the-road analogy (§1)Pedagogical analogy. Restates shallow (bicycle) vs. deep (long-haul truck) vs. coding agent (fitted-out workshop truck), and "the leap is the harness around the engine, not the engine."
Desk-that's-never-cleared analogy (§2)Pedagogical analogy. Restates context rot — piling every document onto the desk and never filing — and "the fix is a system for clearing the desk."
Expedition-not-a-walk analogy (§3)Pedagogical analogy. Restates the four pillars as what a long expedition needs that a walk doesn't.
Surgeon's-whiteboard analogy (§4)Pedagogical analogy. Restates the planning tool as "almost a no-op" that re-orients on a long procedure.
General-contractor-and-the-trades analogy (§5)Pedagogical analogy. Restates hierarchical delegation — specialists in isolated workspaces returning outcomes, not transcripts.
Detective's-case-room analogy (§6)Pedagogical analogy. Restates the filesystem as the context engine (file everything on the walls; pull only the few folders each interview needs).
Constitution-not-the-to-do-list analogy (§7)Pedagogical analogy. Restates the system prompt as principles for the unforeseen, not a flowchart.
Expedition / whole-book whole-chapter analogyPedagogical synthesis and book capstone. No new claims; maps all 11 chapters to the four pillars.
Figures 11.A–11.C (SVGs)Original SVGs. Visually restate the taxonomy, the four-pillar architecture, and the three-box filesystem context engine. The book's figures are diagrams/screenshots and are not reproduced.
The ~/cct-ch11-lab lab (practical exercise)Authored for this training as a framework-free, Claude-Code-+-git-only way to watch each of the four pillars act, so a conceptual chapter becomes hands-on without LangChain, npm, or an API key.

Quiz Item → Source Mapping

Quiz IDAnswerItemSource locationEnrichmentConfidence
q1bThe taxonomy places coding agents (Claude Code, Cursor, Devin, Gemini CLI) as a specialized subset of deep agents (domain of agents → shallow/deep → deep-research/coding), and identifies the application layer / agent harness — not only incremental model gains — as the main driver of progress.Book pp. 1–7 (§1)[E1], [E5], [E13]High
q2aReAct "shallow" agents are limited for long-running tasks because each iteration injects the tool result back into the prompt, so context grows → context rot (bloat, contradiction, pollution) degrading quality and raising latency/cost — while remaining the right tool for few-iteration tasks.Book pp. 3–5 (§2)[E6], [E13]High
q3c"Makes an agent deep": no strict definition — reliable complex, long-running (long-horizon) work, which reduces to smart context management; four building blocks (detailed system prompt, planning tool, subagents, filesystem); and "deep agent" is a community/LangChain-articulated term, not an Anthropic/Claude Code label (Anthropic more commonly discusses "long-running / long-horizon" agentic work rather than defining "deep agent" as an official term).Book pp. 7–8 (§3)[E1]High — terminology clarified (Drift #1, softened in the re-audit).
q4bThe planning tool keeps an explicit, dynamic to-do list (pending/in-progress/completed) the agent rewrites — its real job is context management ("almost a no-op"); the current Claude Code surface is the **Task* tools (TodoWrite/TodoRead legacy, disabled by default); distinct from read-only plan mode**. (The lab no longer tells learners to view the list via /tasks — see Drift #6.)Book pp. 8–9 (§4)[E1], [E10], [E11]High — tool names corrected (Drift #2); plan-mode distinction added.
q5cThe filesystem acts as a "context engine" by (1) writing intermediate state to disk and (2) selecting it back precisely with glob/grep; the three-box model (all-available ⊇ selected vs. required) — make selected small while fully covering required, avoiding under-retrieval, misaligned retrieval, window overflow. Notes "context engine" is a principle, not a feature name.Book pp. 12–15 (§6)[E4], [E6], [E10]High — "context engine" framed as a principle (Drift #3).
q6bSynthesis: subagents / hierarchical delegation — an orchestrator delegates to a specialized subagent with its own system prompt, tools, and isolated context window, which returns only the final result (the Agent tool, formerly Task) — the orchestrator-workers pattern; and the unifying idea that three of the four pillars are context-management moves (plan small + in view; sub-work isolated; state to disk) under a guiding system prompt, which is what lets a finite window sustain long-horizon execution.Book pp. 9–11 (§5) + the four-pillar synthesis[E7], [E8], [E9], [E10]High — the one enrichment-grounded synthesis question. Orchestrator-worker figures "as reported," not Claude Code behavior (Drift #5).

Drift / Corrections Applied

The book is broadly current on the load-bearing concepts (the taxonomy, context rot, the four building blocks, the filesystem-as-context-engine principle), so most adjustments below are clarifications/completions/framing rather than factual errors — with one genuine correction (the planning tool names) and one terminology clarification that the book itself half-acknowledges. The book's original wording is preserved verbatim in extracted-chapters/ and is not edited.

2026-06-16 accuracy pass. Claude Code behavior verified against [E9] subagents, [E10] tools-reference, [E11] permission-modes, [E12] memory. Framework claims attributed to LangChain [E1]–[E4]; orchestrator-worker figures attributed to Anthropic [E7]/[E8] as "as reported." The adjustments below were propagated across the lesson, quiz, this ledger, and the training-output mirror. The rows record each. The book's original wording remains untouched in extracted-chapters/. 2026-06-16 re-audit (second pass — /tasks, CLAUDE.md, pillar numbering, soften "long-horizon"). Re-fetched [E10] tools-reference, [E11]/commands, [E12] memory, [E16] output-styles, and [E17] Agent SDK system-prompt docs. Four corrections propagated across lesson + quiz + this ledger + the training-output mirror: (#6) /tasks misuse — the lesson previously told learners to "run /tasks to see the to-do list," but /tasks is documented as listing background tasks running in the session, not a viewer for the internal planning to-do list; there is no documented viewer command (the checklist surfaces inline). (#7) CLAUDE.md vs system-prompt customization — softened the claim that editing CLAUDE.md is "the same lever" as system prompts/output styles: per [E12]/[E16]/[E17], CLAUDE.md is persistent project memory/context ("context, not enforced configuration," injected into the conversation), while output styles modify the system prompt and the Agent SDK systemPrompt is a separate API surface. (#8) Pillar numbering — made the numbering consistent everywhere on the canonical order 1 system prompt · 2 planning · 3 subagents · 4 filesystem (the §4–§7 lesson headings had used a sequential 1–4; now §4 = Pillar 2, §5 = Pillar 3, §6 = Pillar 4, §7 = Pillar 1, matching Figure 11.B, the §3 list, the objectives, the lab parts, and the success checklist; a one-line teaching-order note was added in §3). (soften #1) "Anthropic's own phrase is 'long-horizon execution'" relaxed to "Anthropic more commonly discusses long-running / long-horizon agentic work, context engineering, and agents/workflows rather than defining 'deep agent' as an official term" (no claim that "long-horizon execution" is a canonical official phrase). The book's original wording remains untouched in extracted-chapters/.
ItemBook / draft positionCurrent / correct positionLesson treatment
1. "Deep agent" terminology (CLARIFICATION)The book's title and framing treat "Deep Agents" as the operative concept, though it does note the LangChain team articulated it clearly after analyzing many implementations."Deep agent" / "deep agents" is a community/LangChain-articulated term, NOT an official Anthropic or Claude Code label — Anthropic's docs and engineering writing more commonly discuss "long-running / long-horizon" agentic work, context engineering, and agents/workflows rather than defining "deep agent" as an official term (the strings "deep agent"/"deep agents" return zero results in code.claude.com docs). [E1] is the term's articulation; the docs absence was verified directly. (Re-audit: softened from "Anthropic's own phrase is 'long-horizon execution'" — see the 2026-06-16 second-pass note.)The preface states it up front; §3 + the currency note repeat it; q3's correct option says "community/LangChain-articulated term … Anthropic more commonly discusses 'long-running / long-horizon' work rather than defining 'deep agent' as an official term"; a common-pitfalls bullet keeps "don't call 'deep agent' an Anthropic feature." Figures 11.A/11.B label the roof "long-horizon execution" (describing the concept, not asserting an official term).
**2. Planning tool — TodoWrite/TodoRead → the Task* family** (CORRECTION)Book describes Claude Code's planning tool as TodoWrite (creates/updates the list, {todos: Todo[]}) and TodoRead (reads it).Per [E10], TodoWrite is disabled by default (as of v2.1.142) in favor of the **Task* family — TaskCreate/TaskList/TaskGet/TaskUpdate/TaskStop**. The concept (an explicit, dynamic to-do list for context management, "almost a no-op" per [E1]) is current and correct; only the tool names moved. (There is no documented user-facing command to view the internal list — see Drift #6; an earlier draft's "viewable via /tasks" was removed.)§4 teaches the concept, names the Task* family as current, and flags TodoWrite/TodoRead as legacy/disabled-by-default; q4's correct option + explanation carry it; Figure 11.B's pillar-2 label reads "Task* (legacy TodoWrite)"; a common-pitfalls bullet says "don't look for a TodoWrite tool — verify at tools-reference." Also distinguishes the in-session to-do list from read-only plan mode ([E11], Chapter 6).
3. "Filesystem as a context engine" — principle, not a feature name (FRAMING / CLARIFICATION)Book section "The filesystem as a context engine" can read as naming a Claude Code capability.Claude Code genuinely ships the file tools (Read/Write/Edit/Glob/Grep/NotebookEdit, [E10]) and memory (CLAUDE.md + auto-memory, [E12]) — those are real, documented surfaces. But the **"filesystem as a context engine" / three-box / write-out-select-back framing is an engineering principle** from Anthropic's Effective context engineering post [E6] and LangChain's filesystem post [E4] — not a documented Claude Code feature name.§6 teaches the file tools + memory as real, then explicitly states the "context engine" framing is a principle (the why), not a button; q5's explanation carries the note; a common-pitfalls bullet says "don't treat 'the filesystem context engine' as a button." Figure 11.C grounds the three-box model in [E4]/[E6].
4. Subagent delegation = the Agent tool (formerly Task) (COMPLETION — carried from Chapter 7)Book describes subagents/hierarchical delegation conceptually (own system prompt, tools, isolated context, returns only the final result) without naming the current tool.Per [E9]/[E10], delegation happens through the Agent tool (renamed from Task; Task remains an alias); the subagent runs in its own context window and returns only its final result — both confirmed by the docs.§5 names the Agent tool (formerly Task) and confirms isolated context + returns-only-the-summary; q6's correct option says "via the Agent tool (formerly Task)"; the practical exercise Part 2 drives the Agent//agents surface.
5. Orchestrator-worker token/eval figures (SOFTENING — background, not behavior)n/a (the book does not cite these; the lesson adds them as enrichment context).The multi-agent research write-up reports an orchestrator-worker system beating a single agent on a research eval **while using substantially more tokens (roughly an order of magnitude, as reported)** — an enrichment/background fact ([E7]/[E8]), not Claude Code behavior or a documented mechanic. The ≈4×/≈15×/≈90.2% figures are "as reported."§5's orchestrator-workers paragraph + q6's explanation present the tradeoff with explicit "as reported / reported background, not Claude Code mechanics" wording; no hardcoded multipliers presented as fact.
6. /tasks is not the to-do-list viewer (CORRECTION — re-audit)An earlier draft told learners to "run /tasks to see the to-do list" (lesson §4, the activity, and lab Part 1).Per [E15], /tasks lists what's running in the background of the current session (background processes), not the in-session planning to-do list. There is no documented user-facing command to view the internal task list ([E15] — "NOT explicitly covered"); the checklist surfaces inline when Claude shows it. The Task* tools ([E10]) maintain the list internally.§4 now says the checklist surfaces inline and explicitly notes /tasks is a different feature (background tasks); the activity's "/tasks to-do list" → "the in-session to-do list (Task* tools)"; lab Part 1 drops "run /tasks" and says watch it inline.
7. CLAUDE.md vs system-prompt customization (CORRECTION — re-audit)An earlier draft said editing CLAUDE.md is "the same lever the system prompt and output styles pull" (lesson §7 + lab Part 4).Per [E12]/[E17], CLAUDE.md is persistent project memory/context — Claude "treats them as context, not enforced configuration," injected into the conversation, not the system prompt. Per [E16], output styles modify the system prompt; per [E17], the Agent SDK systemPrompt is a separate API surface. So CLAUDE.md is not the same mechanism as system-prompt customization.§7 reworded: output styles modify the system prompt and the Agent SDK can replace/append it (the direct surfaces), while CLAUDE.md shapes the same cognitive-baseline pillar from a different mechanism (project memory/context). Lab Part 4 reworded to "different mechanism, same pillar," dropping "same lever."
8. Pillar numbering made consistent (CONSISTENCY — re-audit)The §4–§7 lesson headings numbered the pillars sequentially (planning = Pillar 1, subagents = 2, filesystem = 3, system prompt = 4), conflicting with Figure 11.B, the §3 list, the objectives, the lab parts, and the success checklist, which all use the canonical 1 system prompt · 2 planning · 3 subagents · 4 filesystem.One canonical order applied everywhere: Pillar 1 = detailed system prompt, 2 = planning tool, 3 = subagents, 4 = filesystem.The §4–§7 headings renumbered to canonical (§4 = Pillar 2, §5 = Pillar 3, §6 = Pillar 4, §7 = Pillar 1 — matching the lab parts/checklist/figure); a one-line teaching-order note added in §3 ("we take them in the book's order — planning first — but each keeps its number"); the lab Part 1 "Pillar 1's planning tool" → "Pillar 2's"; lab Part 4 "(Pillar 4)" → "(Pillar 1)".
Source boundary (FRAMING)n/aClaude Code behavior rests on [E9]–[E12]; the LangChain materials [E1]–[E4] are authoritative for the framework's design and the "deep agent" term but NOT for Claude Code behavior; Anthropic engineering/research/cookbook [E5]–[E8] are concept/background (orchestrator-worker figures "as reported," never Claude Code behavior); ReAct [E13] is the academic foundation.The lesson cites [E1]–[E8], [E13], [E14] in Further reading with explicit labels ("treat as LangChain's design philosophy, not Claude Code behavior"; "Token/eval figures are 'as reported' background, never Claude Code behavior"); behavior claims rest on the docs.
Canonical docs host (NOTE)n/aThe canonical host is code.claude.com; docs.claude.com mirrors.The lesson and Further reading cite code.claude.com / langchain.com / blog.langchain.com / anthropic.com / platform.claude.com throughout.

Extraction caveat (image-only PDF, summarized prose)

source-pdfs/11-chapter-11.pdf is an image-only PDF — no text layer (the image-only check printed 0). The source-of-truth extracted-chapters/11-chapter-11.md was produced by rendering each of the 20 pages to PNG at 150 DPI (PyMuPDF / fitz) into work/11-chapter-11-pages/ and transcribing the images visually. Consequences a reviewer should know:

  • Mixed-fidelity extract. Explanatory prose is captured as faithful summaries; headings, code, commands, file paths, key names, flags, tool names, and the LangChain base_prompt.md excerpt are verbatim. Treat code/commands/paths/tool-names/the prompt excerpt as exact; treat prose as a structural summary. Re-open the page images in work/11-chapter-11-pages/ for exact sentence wording.
  • Page markers are reliable, but printed book page numbers are unknown — <!-- page N --> is the PDF page index. There is no .txt mirror.
  • needs review — page-1 "topics covered" list is truncated by the page break. Only two bullets render before the page cuts off — "Agent taxonomy in production systems" and "What makes an agent deep" — and the "Understanding Deep Agents" section heading itself is split across pages 1/2 (the word "systems" continues at the top of page 2). The section headings later in the chapter confirm the rest of the covered topics (planning tool, subagents, filesystem, system prompt), so the full bullet list clearly continued onto an uncaptured portion of the page. Cross-check the printed book if the exact "topics covered" list matters.
  • The book's figures are diagrams and screenshots (Figure 11.1 taxonomy nested-boxes; Figures 11.2/11.3 hybrid-RAG / ReAct flowcharts; Figure 11.4 context-accumulation panels; Figure 11.5 deep-agent architecture, adapted from the LangChain blog; Figures 11.6/11.7 subagent tree + Claude Code terminal screenshot; Figure 11.8 file-tools terminal screenshot; Figure 11.9 three-box Venn, sourced from the LangChain filesystem post) and are not reproduced (the three lesson diagrams are original SVGs).
  • Page 20 is Packt back-matter promo (a "Scan the QR code / packtpub.com/unlock" unlock offer with a QR image and Previous/Next-Section nav; the partial heading reads "…bundle, and more"), not chapter content — ignore it for sourcing.
  • Re-transcription, not OCR. PyMuPDF was used to render pages; no OCR engine was involved. Cross-check the printed book if exact wording/pagination matters.
Chapter 12: Capstone Project

Source Ledger — Capstone Project

Primary source (NOT a book chapter)

There is no book chapter behind this unit. The Capstone is original pedagogical synthesis — it recombines the skills taught across Chapters 1–11 into one integrative, hands-on build, and adds a cumulative final exam. Consequences for sourcing:

  • No source PDF. There is no source-pdfs/12-*.pdf. The capstone was not extracted from a book; it was designed from scratch (design-of-record in work/capstone-design.md, approved 2026-06-16).
  • No extracted-chapters/ file. Because there is no PDF, there is no extracted-chapters/12-capstone.txt or .md. There is nothing to extract and nothing to treat as a verbatim source-of-truth — the lesson itself is the primary artifact, and its grounding is the corrected-canonical facts established across the eleven chapter audits (see Grounding & conventions at the end).
  • Unit metadata. Slug 12-capstone (sorts/files after 11-chapter-11); Part 4 — Capstone (its own sidebar heading); kind: capstone (not a numbered chapter); displayed title "Capstone Project" (not "Chapter 12"); status ready; estimatedMinutes 120 (~90–120 min build + ~20 min exam). It re-uses the existing [slug].astro route and the generic quiz component — no new components or routes.
  • Framework-free, like every chapter lab. Claude Code + git + a throwaway Python-stdlib devlog sandbox in ~/cct-capstone-lab/. No npm/Node, no accounts, no cloud, no API keys. The devlog CLI (add/list/summary core; search/export parallel features; one devlog.json store; json/argparse/datetime/pathlib only) is an original teaching artifact, chosen because it has a natural hook for every chapter's skill.

Enrichment sources

The Capstone introduces no new external sources. Every Claude Code behavior claim it makes is re-used from the eleven chapter ledgers and rests on the canonical Claude Code docs already cited there (https://code.claude.com/docs/en/..., with docs.claude.com mirroring). Per project convention, no inline > Source: / > Enrichment — … labels appear in the learner-facing lesson — and in this lab-shaped finale the only in-lesson labelled callout is the single closing > Analogy — the solo flight box. This ledger is the single source of provenance.

The docs surfaces the capstone leans on (all previously cited across Chapters 1–11, listed here by the chapter that owns each fact):

  • [Ch1] Context engineering / context rot / the four strategies (write · select · compress · isolate) — Chapter 1's ledger and the Effective context engineering engineering post.
  • [Ch2] CLAUDE.md / /init as project memory — https://code.claude.com/docs/en/memory.
  • [Ch3] Settings, permissions, hooks (deterministic vs. prose) — https://code.claude.com/docs/en/hooks, …/settings.
  • [Ch4] MCP scopes (local/project/user), .mcp.json, --scope project, the -- separator, deferred tool definitions — https://code.claude.com/docs/en/mcp.
  • [Ch5] anthropics/claude-code-action@v1, the claude/ branch, headless Agent SDK, two-credential model, no auto-merge by default — https://code.claude.com/docs/en/github-actions.
  • [Ch6] Plan mode (read-only; reads/searches/MCP but no edit/commit/install until approved); spec-driven development — https://code.claude.com/docs/en/permission-modes.
  • [Ch7] Subagents — tools allowlist, the Agent tool (formerly Task), isolated context returning a summary — https://code.claude.com/docs/en/sub-agents.
  • [Ch8] Output styles modify the system prompt; selected via /config (the removed /output-style); read once at session start; keep-coding-instructions — https://code.claude.com/docs/en/output-styles.
  • [Ch9] Skills — progressive disclosure / selection routes on the listing (description); body persists in-session; ${CLAUDE_SKILL_DIR}; allowed-tools is a grant — https://code.claude.com/docs/en/skills.
  • **[Ch10] Cloud/background session = fresh clone; repo-committed config travels, user-local (incl. claude mcp add) doesn't; worktree.baseRef governs local worktrees; the integrate-test-merge pattern** — https://code.claude.com/docs/en/claude-code-on-the-web, …/worktrees.
  • **[Ch11] The four deep-agent pillars; "deep agent" is a community/LangChain term not an official label; Task* family current / TodoWrite legacy** — Chapter 11's ledger + …/tools-reference.

Pedagogical enrichment by the training author

Everything in the Capstone is, in a sense, pedagogical authorship — it is original synthesis, not extraction. The items below are the parts that are purely the training author's invention (no analogue in any chapter or in the docs), inventoried for separate audit.

  • Newcomer preface (## Before we start — what this capstone is). Explains the finale framing ("you learned the moves one at a time; here you run them end to end"), names the devlog build, restates "framework-free, like every lab," and explains the two-part assessment (success checklist + final exam, 9/12 to pass). No new claims — it summarizes the unit.
  • "Why a capstone" section. Argues that knowing each tool isn't the same as knowing which tool, when — the judgment the capstone exercises. Pedagogical framing only.
  • Figure 12.A (one original SVG). A map of the six build stages in sequence, each tagged with the chapters it exercises, converging on the four deep-agent pillars (with MCP / the Action placed in the picture). figcaption notes it is "Pedagogical diagram by this training, not from the book." This is the only diagram in the unit (intentional — see Grounding & conventions).
  • The devlog CLI spec. An original, deliberately tiny tool (add/list/summary + search/export; one JSON store; stdlib only). The load-bearing gotcha — entries are append-only and an entry's id is a stable reference (never renumber/reuse) — is an original teaching device that deliberately echoes Chapter 5's break-then-fix lesson ("one load-bearing fact the agent must not break"), surfaced through CLAUDE.md.
  • Stages 0–6 — the staged walkthrough. Original sequencing that recombines the chapter skills into one build (each stage maps to specific chapters — see the Stage→Source table). Copy-paste commands + an "Expected outcome" per stage follow the practical-exercise pattern of the chapter labs.
  • Success checklist (one box per stage + the exam) and Common pitfalls block. Original; restate the stage goals and the chapter routing rules (skill vs. subagent vs. MCP vs. hook).
  • Closing analogy (> Analogy — the solo flight). One sustained analogy: the eleven chapters were lessons with the instructor's hands near the controls; the capstone is the solo flight — same aircraft, same procedures, but the judgment is now the learner's. This is the single** analogy in the unit (intentional — see Grounding & conventions).
  • "Further practice" coda — apply the same arc to the learner's own repo. Optional, ungraded.

The final-exam items and the six objectives are grounded in the chapters and their corrected-canonical facts; none of the analogy, Figure 12.A, the devlog sandbox, the checklist, or the stage prose is itself assessed.

Objective → Source Mapping

Learning ObjectiveStage(s)Chapter sourceConfidenceNotes
Stand up a Claude Code project from scratch — a sandbox repo, a CLAUDE.md capturing conventions and a deliberate load-bearing gotcha, and a sensible permission posture.Stage 0Ch1 (context engineering), Ch2 (CLAUDE.md//init), Ch3 (settings/permissions/memory)HighCLAUDE.md framed as project memory/context, not a system-prompt edit (Ch11 re-audit correction); the gotcha rides on it.
Drive spec-first development in plan mode: design the data model and commands read-only, then export a committed spec before any code is written.Stage 1Ch6 (plan mode, spec-driven development)HighPlan mode is read-only (reads/searches/analyzes/MCP, normal prompts) — no edits/commits/installs until approved. Spec → committed .claude/devlog-spec.md as durable repo context.
Build a working tool under the permission gate, then extend Claude Code itself with a packaged skill and an output style.Stage 2, Stage 3Ch2–3 (permission gate, approving edits), Ch9 (skills), Ch8 (output styles)HighSkill selection routes on the description; scripts via ${CLAUDE_SKILL_DIR}. Output styles selected via /config (the removed /output-style); read once at session start.
Delegate a scoped code review to a least-privilege subagent and act on the summary it returns from its isolated context.Stage 4Ch7 (subagents)Hightools is a genuine allowlist (read-only here); delegation via the Agent tool (formerly Task); isolated context returns only a summary.
Run two independent features in parallel git worktrees and integrate-test-merge them safely.Stage 5Ch10 (worktrees, integrate-test-then-push)HighVerify each worktree session's starting branch first (a wrong base poisons the merge); integrate on a throwaway branch → test → merge → clean up.
Map the finished build onto the four deep-agent pillars and place MCP and the GitHub Action in that picture — then pass a cumulative exam spanning all 11 chapters.Stage 6 + the examCh11 (four pillars), Ch4 (MCP), Ch5 (the Action)HighPillars 1 system prompt · 2 planning · 3 subagents · 4 filesystem. MCP scopes local/project/user + .mcp.json; Action @v1 on a claude/ branch. Exam = all 11 chapters.

Lesson / Stage → Source Mapping

Lesson section / StageChapter sourceConfidenceNotes
Preface — what this capstone is (finale framing, the devlog build, framework-free, two-part assessment)Synthesis of Chapters 1–11HighPedagogical framing; no new claims.
"Why a capstone" — knowing each tool ≠ knowing which tool whenPedagogicalHighOriginal framing of the synthesis goal.
Figure 12.A — the six stages → the four pillarsn/a — pedagogical diagramn/aThe only SVG in the unit (intentional for a lab-shaped finale). figcaption flags it as not from the book.
The devlog CLI spec — storage, core commands, parallel features, the append-only / stable-id gotcha, stdlib onlyPedagogical (gotcha echoes Ch5 break-then-fix)HighOriginal teaching artifact. The gotcha is the deliberate "one load-bearing fact the agent must not break" trap, surfaced via CLAUDE.md.
Stage 0 — set up the sandbox; author CLAUDE.md (stdlib rule + the append-only / stable-id gotcha); permission posture; (hook enforces where CLAUDE.md only instructs)Ch1, Ch2, Ch3HighCLAUDE.md = project memory; the "hook enforces deterministically, CLAUDE.md only instructs" aside is the Ch3 fact.
Stage 1 — enter plan mode (/plan, Shift+Tab, or --permission-mode plan); design read-only; export to a committed .claude/devlog-spec.mdCh6HighPlan mode read-only; explore → plan → commit-the-spec → code loop; the committed spec is durable repo context the agent can re-read.
Stage 2 — implement add/list/summary under the permission gate; exercise it; confirm stable, append-only idsCh2, Ch3HighApprove edits as the gate prompts; the CLAUDE.md gotcha doing its job (agent appends, doesn't renumber).
Stage 3 — package a release-notes skill (.claude/skills/release-notes/, SKILL.md, scripts via ${CLAUDE_SKILL_DIR}), invoked by description; set a terse-structured output style via /configCh9 (skills), Ch8 (output styles)HighSkill routes on the description (Ch9); the /output-style command was removed → select via /config/the outputStyle setting; style change takes effect after /clear (Ch8).
Stage 4 — create a least-privilege devlog-reviewer subagent (read-only Read/Grep/Glob allowlist); delegate; it returns a summary from an isolated context (/context stays lean)Ch7Hightools is a genuine allowlist; delegation via the Agent tool; isolated context returns only the summary.
Stage 5 — two parallel worktrees (git worktree add; CC shortcut claude --worktree); verify each starting branch; integrate on a throwaway branch → test before merging → merge to main → clean upCh10HighThe integrate-test-then-push pattern; "a wrong starting branch silently poisons the merge" is the Ch10 caveat; cleanup per the Ch10 checklist.
Stage 6 — reflect: map Stages 0–5 onto the four pillars (① system prompt/CLAUDE.md · ② planning · ③ subagents · ④ filesystem); place MCP (local/project/user, .mcp.json, deferred tools) and the Action (@v1, claude/ branch, scoped App + model secret, human-reviewed PR)Ch11, Ch4, Ch5HighPillar numbering follows the Ch11 canonical order. MCP/Action are touched conceptually (account/stack-heavy → carried by the exam), not built.
Success checklist (one box per stage + the exam)Recap of Stages 0–6HighOriginal; the assessment surface for the build half.
Common pitfalls (skip-the-spec, renumbered ids, wrong worktree branch, wrong primitive, over-privileged reviewer)Ch5, Ch6, Ch7, Ch9, Ch10HighRestates the routing rule (skill / subagent / MCP / hook) and the least-privilege reviewer point.
Closing analogy — the solo flightn/a — pedagogicaln/aThe only analogy in the unit (intentional). No new claims.
"Further practice" coda — do the arc on your own repoPedagogicalHighOptional, ungraded.

Unsupported / Pedagogical-Only Claims

ItemJustification
The "solo flight" closing analogyPedagogical analogy. Restates the finale framing — the chapters were instructor-guided lessons; the capstone is the solo flight where the judgment becomes the learner's. No factual claim. The single analogy in the unit (the lab-shaped finale follows the practical-exercise pattern, not the per-section-analogy lesson pattern).
Figure 12.A (SVG)Original SVG. Visually maps the six build stages to the chapters they exercise and to the four deep-agent pillars (with MCP / the Action placed). The only diagram in the unit. figcaption flags it as not from the book.
The devlog CLI sandboxOriginal teaching artifact authored for this training: a tiny Python-stdlib work-journal CLI chosen because it offers a natural hook for every chapter's skill, runnable framework-free (Claude Code + git only, no npm/accounts/cloud). The append-only / stable-id gotcha is a deliberate teaching device echoing Chapter 5.

Quiz Item → Source Mapping (cumulative final exam)

12 questions, passing score 9/12. Application/scenario-flavored, one per chapter (1–11) plus one synthesis/routing question, all grounded in the corrected-canonical facts.

Quiz IDAnswerChapterItemConfidence
q1bCh1Mid-session degradation = the finite context window / attention budget suffering context rot; apply the four strategies (write / select / compress (/compact) / isolate in subagents). A bigger model doesn't remove the finite-window problem.High
q2aCh2/Ch3 + Ch11 correctionCLAUDE.md is persistent project memory/context ("context, not enforced configuration"), NOT a system-prompt edit; it instructs but doesn't guarantee — for a must-hold rule, use a hook.High — carries the Ch11 re-audit CLAUDE.md-vs-system-prompt correction.
q3cCh3A must-run-every-commit step belongs in a hook (harness-executed deterministically on its event, can block on exit 2), not a skill's prose (instructs, not guaranteed). Hooks are not a security boundary.High
q4dCh4Team-shared MCP server → --scope project writes the committed .mcp.json; default scope is local (~/.claude.json), so a bare claude mcp add does not create .mcp.json; local installs need the -- separator; scopes are local/project/user — no 'session' scope; ~/.claude/settings.json is not the MCP file.High — carries the full Ch4 scope/path corrections.
q5aCh5@claude → anthropics/claude-code-action@v1 runs headless on the Agent SDK, works on a separate branch under the claude/ prefix (never main), pushes a branch + PR for human review (no auto-merge by default); two credentials — the scoped Claude GitHub App + a separate model secret (OAuth token or API key).High — carries the Ch5 @v1 / branch / no-auto-merge corrections.
q6bCh6Plan mode is read-only: reads/searches/analyzes/MCP (with normal prompts) but cannot edit/create/delete/commit/install until you approve and exit. Distinct from the in-session to-do list.High
q7cCh7Read-only tools allowlist (Read/Grep/Glob — no Write/Edit/Bash); delegate via the Agent tool (formerly Task); subagent runs in its own isolated context window and returns only a summary (omitting tools would over-privilege).High
q8aCh8An output style (it modifies the system prompt); select via /config → Output style or the outputStyle setting (the standalone /output-style was removed); read once at session start (effective after /clear); a custom style drops coding instructions unless keep-coding-instructions: true.High
q9bCh9Progressive disclosure: selection routes on the listing / description (when_to_use appended; first body paragraph only if no description) — fix the description, not deep body text; the body persists in-session (recurring token cost — keep it lean); scripts via ${CLAUDE_SKILL_DIR}; allowed-tools is a pre-approval grant, not a trigger or restriction.High
q10bCh10A cloud/background session is a fresh clone — repo-committed config travels (CLAUDE.md, .claude/settings.json hooks, .mcp.json, `.claude/skills\agents\commands); user-local config doesn't, and claude mcp add writes local user config (not the repo). Fix: commit the server to .mcp.json. **worktree.baseRef` governs local worktrees, not cloud checkout.**High — carries the Ch10 re-audit corrections.
q11cCh11"Deep agent" is a community/LangChain-articulated term, NOT an official Anthropic/Claude Code label (Anthropic more commonly discusses long-running / long-horizon work); current task-tracking is the **Task* family** (TodoWrite/TodoRead legacy/disabled by default); the four building blocks = detailed system prompt · planning tool · subagents · filesystem.High — carries the Ch11 "deep agent" terminology + Task* corrections.
q12aSynthesis (Ch3, Ch4, Ch7, Ch9)Routing: (a) recurring chore → Skill; (b) heavy/isolating audit → Subagent; (c) external/live data → MCP server; (d) must-run-every-time → Hook. Matching the shape of the work to the primitive is the synthesis skill the course builds toward.High — the one cross-chapter synthesis item.

Drift / Corrections Applied

The Capstone has no book source, so there is no book wording to correct here. Its sole drift discipline is: it asserts only the post-audit, corrected-canonical forms of every Claude Code surface it touches — i.e. it is consistent with the 2026-06-16 course-wide sweep and the Chapter 10/11 re-audits, and does not reintroduce any stale wording the chapter audits removed.

Concretely, the capstone asserts the corrected forms (and never the stale ones):

SurfaceStale form the capstone does NOT useCorrected form the capstone usesWhere it appears
Subagent delegation tool"Task tool" as the current nameAgent tool (formerly Task)Stage 4, q7
Task trackingTodoWrite/TodoRead as current**Task* family current; TodoWrite/TodoRead legacy/disabled by default**q11, Figure 12.A label
MCP scopes"project / user / session"local / project / user (no 'session'); default local; --scope project → committed .mcp.json; -- separatorStage 6, q4
GitHub Action@beta; auto-merge; commits to main@v1; claude/ branch never main; no auto-merge by default; two credentials (scoped App + model secret); headless Agent SDKStage 6, q5
Output stylesthe /output-style command/config (or the outputStyle setting); /output-style removed; read once at session start; keep-coding-instructionsStage 3, q8
"Deep agent"an official Anthropic/Claude Code labela community/LangChain-articulated term; Anthropic discusses long-running / long-horizon workStage 6, q11
Cloud sessions"no config at all" / mirrors your machinefresh clone; repo-committed config travels, user-local (incl. claude mcp add) doesn't; worktree.baseRef is local worktrees onlyq10
CLAUDE.md"rewrites the system prompt" / "enforced configuration" / "same lever as an output style"persistent project memory/context ("context, not enforced configuration"); instructs, doesn't guarantee; distinct from system-prompt customizationStage 0, Stage 6 ①, q2
Hooksa security boundarydeterministic, harness-executed on their event (can block on exit 2); not a security boundaryStage 0 aside, q3
Skill triggeringtrigger phrases in the body / allowed-tools triggers/restrictsroutes on the description listing; body persists in-session; ${CLAUDE_SKILL_DIR}; allowed-tools is a grantStage 3, q9
Plan modeedits then shows a plan / disables the modelread-only (reads/searches/MCP) — no edit/commit/install until approvedStage 1, q6
Canonical docs hostn/acode.claude.com (with docs.claude.com mirroring)throughout (consistency)

No extracted-chapters/ file exists to leave untouched; the corrected forms above are the capstone's only source-of-truth, inherited from the eleven chapter ledgers.

Grounding & conventions (in place of an Extraction caveat)

Because there is no PDF and no extract, the usual Extraction caveat does not apply. In its place, a reviewer should know:

  • No PDF / no extract / no .txt-or-.md source-of-truth. The lesson is the primary artifact. There is nothing to re-open for "exact book wording," because there is no book chapter — the unit is original synthesis. The design-of-record is work/capstone-design.md (approved 2026-06-16); it is a design spec, not a source text.
  • **All Claude Code behavior claims are grounded in the corrected-canonical facts established across the eleven chapter audits — specifically the surfaces enumerated in the Drift / Corrections** table above (the Agent tool not "Task tool"; Task* family not TodoWrite-as-current; MCP local/project/user scopes; the Action @v1; output styles via /config; "deep agent" as a community term; cloud repo-committed-config; CLAUDE.md as project memory not a system-prompt edit; hooks deterministic-not-a-security-boundary; plan mode read-only; skill selection routes on the description). The capstone introduces no new external sources and re-uses these corrected facts; it does not re-derive any claim from memory.
  • Intentional convention deviation — lab-shaped, not the standard lesson shape. The Capstone is project/lab-shaped, so it intentionally follows the practical-exercise pattern (Stages with copy-paste commands + an "Expected outcome" per stage), NOT the standard chapter lesson pattern (a > Analogy — … callout per numbered section + multiple original SVGs woven through the body). Accordingly it has one closing analogy ("the solo flight") and one original SVG (Figure 12.A) — by design, not by omission. This is the correct shape for a hands-on finale; a reviewer should not flag the missing per-section analogies or additional diagrams as a defect.
  • Title / numbering. Rendered as "Capstone Project" (not "Chapter 12"); kind: capstone, Part 4. Verify the chapter-page template does not hard-render "Chapter {number}" in a way that mislabels it.
  • Assessment shape differs from a chapter. 12 questions, passing score 9/12 (≈75%) — the only quiz in the course with more than 6 questions and a non-5 passing score. The generic quiz component handles both (passingScore is a field; questions is an array) — verify rendering and the "Passed" threshold during build verification.