Learning objectives

By the end of this chapter, you will be able to:

1. 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 (Chapters 1–3).
2. 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 (Chapter 6).
3. Build a working tool under the permission gate, then extend Claude Code itself with a packaged **skill** and an **output style** (Chapters 2–3, 8–9).
4. Delegate a scoped code review to a least-privilege **subagent** and act on the summary it returns from its isolated context (Chapter 7).
5. Run two independent features in **parallel git worktrees** and integrate-test-merge them safely (Chapter 10).
6. Map the finished build onto the **four deep-agent pillars** and place MCP and the GitHub Action in that picture (Chapters 11, 4, 5) — then pass a cumulative exam spanning all 11 chapters.

Before we start — what this capstone is

This is the finale. Across eleven chapters you learned the moves one at a time; here you run them end to end on a single build, reaching for the right tool at the right moment. There's nothing new to learn — it's a chance to feel how the pieces fit, and to prove to yourself that you can drive Claude Code through a real piece of work.

What you'll build. A tiny devlog — a per-project work journal / changelog: a Python-stdlib CLI backed by one JSON file, with add, list, and summary commands, plus two features (search, export) you'll build in parallel. It's deliberately small; the point is the workflow around it, not the program.

Framework-free, like every lab in this course. You need only Claude Code, git, and a shell — no npm/Node, no accounts, no cloud. Everything happens in a throwaway sandbox; nothing here touches anything else on your machine.

How it's assessed. Two parts: (1) the success checklist at the end of the build — work through the stages and tick each box; and (2) the final exam below this page (12 questions drawn from all eleven chapters, passing score 9/12). Passing the exam marks the course complete.

How to read this. Work the stages in order — each has a Goal, the chapters it draws on, copy-pasteable steps, and an Expected outcome so you can check yourself. The prompts you give Claude are suggestions; phrase them your own way. If a step doesn't behave exactly as written (Claude Code moves fast), fall back to the chapter it came from.

Why a capstone

A course of isolated skills leaves a gap: knowing each tool isn't the same as knowing which tool, when. Real work is a stream of small decisions — "is this a job for a skill or a subagent?", "should I plan first or just edit?", "are these two features safe to run in parallel?" The capstone is where those decisions come at you together, on one build, so the judgment becomes yours. When you finish, you'll have done — in miniature — exactly what every chapter was preparing you for: drive a capable agent through a long-horizon task without losing control of the code.

The build — the devlog CLI

You're building a small work journal. The spec is intentionally tiny so the workflow is the star:

• Storage: one file, devlog.json — a JSON list of entries, each { "id": <int>, "ts": <string>, "text": <string>, "tags": [<string>...] }.
• Core commands (Stage 2): add "<text>" [--tag T], list [--tag T], summary (totals + counts by tag).
• Parallel features (Stage 5): search <query> and export --format md|json.
• The one rule that matters — your load-bearing gotcha: entries are append-only, and an entry's id is a stable reference — never renumber or reuse ids. (Later, the release-notes skill and export refer to entries by id; renumbering silently breaks them. This is the same "one load-bearing fact the agent must not break" lesson as Chapter 5 — and you'll put it in CLAUDE.md so the agent respects it.)
• Stdlib only: json, argparse, datetime, pathlib. A handful of asserts or a tiny unittest is your "test" gate.

Stage 0 — Set up the project and its memory

Goal: a sandbox repo with project memory and a permission posture in place, before any feature work. Draws on: Chapter 1 (context engineering), Chapter 2 (CLAUDE.md / /init), Chapter 3 (settings, permissions, memory).

Create the sandbox:

mkdir -p ~/cct-capstone-lab && cd ~/cct-capstone-lab
git init -q
printf '# devlog\nA tiny project work-journal CLI (capstone build).\n' > README.md
git add . && git commit -q -m "init capstone sandbox"

Start claude in the sandbox. Author a CLAUDE.md — either with /init and then edit, or by asking directly:

Create a CLAUDE.md for this project. Record these conventions:
- This is a Python-stdlib CLI; no third-party dependencies, ever.
- Data lives in devlog.json as a JSON list of {id, ts, text, tags}.
- LOAD-BEARING: entries are append-only. An entry's `id` is a stable
  reference used elsewhere — NEVER renumber, reuse, or mutate existing ids.
- Prefer the simplest change that works; read a file before editing it.

Expected outcome: a committed sandbox and a CLAUDE.md that states the stdlib rule and — prominently — the append-only / stable-id gotcha. This is your project's memory; every later stage rides on it. (If you want a stricter guardrail than prose, recall Chapter 3: a hook enforces deterministically where CLAUDE.md only instructs — optional here.)

Stage 1 — Plan the build in plan mode

Goal: a reviewed spec on disk before a line of code. Draws on: Chapter 6 (plan mode, spec-driven development).

Enter plan mode (/plan, or Shift+Tab to the plan permission mode) and ask Claude to design — not build — the tool:

/plan Design the devlog CLI: the devlog.json schema, the add/list/summary
commands and their flags, timestamp handling, and the edge cases (empty log,
missing file, unknown --tag). Don't write code yet — propose a plan.

Refine the plan through feedback, then export it to a committed spec so it becomes durable repo context:

Write the approved design to .claude/devlog-spec.md, then exit plan mode.

Expected outcome: Claude explored read-only and produced a plan (no files changed in plan mode); you exported it to .claude/devlog-spec.md and committed it. You now have the explore → plan → (commit the spec) → code loop in motion — and a spec the agent can re-read instead of re-deriving.

Stage 2 — Build the core under the permission gate

Goal: a working add/list/summary, with the gotcha respected. Draws on: Chapter 2–3 (the permission gate, approving edits).

Ask Claude to implement the spec:

Implement devlog.py per .claude/devlog-spec.md: add, list, and summary,
backed by devlog.json. Honor the append-only / stable-id rule from CLAUDE.md.

Approve the edits as the permission gate prompts. Then exercise it:

python devlog.py add "Set up the sandbox" --tag setup
python devlog.py add "Planned the CLI in plan mode" --tag plan
python devlog.py list
python devlog.py summary
cat devlog.json   # confirm ids are 1, 2 (stable, append-only)

Expected outcome: a working CLI; devlog.json shows sequential, stable ids; summary reports totals by tag. Commit it. (Watch that the agent appended rather than rewriting the file — the CLAUDE.md gotcha doing its job.)

Stage 3 — Extend Claude Code: a skill + an output style

Goal: package a recurring task as a reusable skill, and set a session communication style. Draws on: Chapter 9 (skills), Chapter 8 (output styles).

The skill — turn "summarize the log into release notes" into a packaged workflow:

Create a project skill `release-notes` at .claude/skills/release-notes/.
Its job: read devlog.json and produce a Markdown changelog grouped by tag,
referencing entries by their stable id. Put the steps in SKILL.md; if it
needs a script, reference it with ${CLAUDE_SKILL_DIR}.

Then trigger it by description (don't type the slash): give me release notes for the project so far.

The output style — set a terse, structured session voice:

Create a project output style "terse-structured" that makes responses short,
bulleted, and code-first. Then switch to it.

(Recall Chapter 8: select styles via /config → Output style or the outputStyle setting — the standalone /output-style command was removed — and a style change takes effect after /clear or a new session.)

Expected outcome: /skills lists release-notes, and a natural-language request invoked it (the description routed it — Chapter 9); the changelog references entries by id. After /clear, responses follow the new style. You've extended Claude Code itself, not just the project.

Stage 4 — Delegate a review to a subagent

Goal: a scoped, isolated review that returns a summary. Draws on: Chapter 7 (subagents).

Create a least-privilege reviewer and delegate to it:

Create a subagent "devlog-reviewer" with read-only tools (Read, Grep, Glob —
no Write/Edit/Bash). Then use it to review devlog.py for bugs and edge cases
and report back a summary.

Expected outcome: the subagent ran in its own context window and returned a summary (you didn't see its every step in the main thread — run /context to see the main window stayed lean). Its tools list is a genuine allowlist (Chapter 7). Apply any fixes it surfaced in the main session, and commit.

Stage 5 — Two features in parallel worktrees, then merge

Goal: build two independent features at once, then integrate-test-merge. Draws on: Chapter 10 (worktrees, the integrate-test-then-push pattern).

search and export touch different code paths, so they're safe to parallelize. Create two worktrees (the mechanism Chapter 10 explains; Claude Code's own shortcut is claude --worktree <name>):

cd ~/cct-capstone-lab
git worktree add ../cap-search -b feat/search
git worktree add ../cap-export -b feat/export
git worktree list

In each worktree, run a focused claude session scoped to that one feature — verify each is on its own branch first (the Chapter 10 lesson: a wrong starting branch silently poisons the merge):

# in ../cap-search:  "Add a `search <query>` command that prints matching entries. Touch only the search path."
# in ../cap-export:  "Add an `export --format md|json` command. Touch only the export path."

Then integrate on a throwaway branch, test before merging, and only then merge to the main branch:

cd ~/cct-capstone-lab
git checkout -q -b integrate
git merge --no-edit feat/search
git merge --no-edit feat/export
python devlog.py search setup && python devlog.py export --format md   # TEST the merged result
git checkout -q main && git merge --no-edit integrate                  # only after it passes
git worktree remove ../cap-search && git worktree remove ../cap-export  # clean up (Ch10 checklist)

Expected outcome: both features built in isolation, integrated on a throwaway branch, tested, then merged to main; worktrees cleaned up. You ran the full Chapter 10 pattern — parallel isolation → integrate → test → merge — by hand.

Stage 6 — Reflect: the four pillars (and where MCP and the Action fit)

Goal: see the architecture you just operated. Draws on: Chapter 11 (deep agents), Chapter 4 (MCP), Chapter 5 (the GitHub Action).

Look back over Stages 0–5 and map what you did onto the four deep-agent pillars (Chapter 11):

• ① The system prompt / project memory — your CLAUDE.md (the gotcha, the conventions) shaped how the agent thought the whole way through.
• ② Planning — plan mode + the committed spec kept a long task oriented.
• ③ Subagents — the reviewer did heavy work in an isolated context and returned a summary.
• ④ The filesystem — devlog.json, the spec, the skill, and git worktrees were all state on disk, kept out of the context window and pulled back in only as needed.

Then place the two surfaces this framework-free build only touched:

• MCP (Chapter 4): if devlog needed to read from an external tracker (Jira, a database), you'd expose that as an MCP server — added at local/project/user scope, declared in .mcp.json for the team, its tool definitions deferred by default. Where would an MCP server slot into devlog? Name one.
• The GitHub Action (Chapter 5): to run devlog checks unattended on every PR, you'd wire anthropics/claude-code-action@v1 into .github/workflows/, with the scoped GitHub App + a model credential as a secret — Claude works on a claude/ branch, never main, with a human reviewing the PR. What check would you have it run?

Expected outcome: you can name, for your own build, where each pillar showed up and where MCP and the Action would extend it. That's the whole course, seen from above.

Success checklist

• [ ] Stage 0 — sandbox + a CLAUDE.md stating the stdlib rule and the append-only / stable-id gotcha (Ch 1–3).
• [ ] Stage 1 — designed in plan mode (read-only) and exported a committed .claude/devlog-spec.md (Ch 6).
• [ ] Stage 2 — add/list/summary work; devlog.json ids are stable and append-only (Ch 2–3).
• [ ] Stage 3 — a release-notes skill that a natural-language request invoked, plus a custom output style in effect (Ch 8–9).
• [ ] Stage 4 — a least-privilege subagent reviewed the code in an isolated context and returned a summary (Ch 7).
• [ ] Stage 5 — search + export built in parallel worktrees, integrated-tested-merged, worktrees cleaned up (Ch 10).
• [ ] Stage 6 — mapped the build to the four pillars and placed MCP + the Action (Ch 11, 4, 5).
• [ ] You passed the final exam below (9/12).

Common pitfalls - Skipping the spec and "just building." Plan mode + a committed spec is what keeps a multi-step build coherent (Ch6) — don't skip Stage 1. - Letting the agent renumber ids. If devlog.json ids change, your skill and export break — exactly the load-bearing gotcha. If it happens, your CLAUDE.md rule wasn't prominent enough (Ch5). - A wrong starting branch in a worktree. Verify each worktree session is on its own feature branch before it works; a wrong base poisons the merge (Ch10). - Reaching for the wrong primitive. Recurring procedure → a skill; heavy/iso­lated work → a subagent; external system → MCP; must-run-every-time → a hook (Ch9's routing rule). - Over-privileging the reviewer subagent. Give it read-only tools — a reviewer has no business writing files (Ch7, least privilege).

The whole course in one image

Analogy — the solo flight

Every chapter was a lesson with the instructor's hands near the controls: here's the throttle (context engineering), here's how you talk to the tower (CLAUDE.md), here's how you read the instruments (plan mode), how you hand off to the co-pilot (subagents), how you run two engines at once (worktrees). The capstone is the solo flight — same aircraft, same procedures, but now you take it up, run the checklist, handle the radio, and bring it back down. Nothing new happens on a solo flight; what changes is that the judgment is yours. When you land this devlog, you're not someone who has heard about agentic coding — you're someone who has done it, start to finish. That's the certificate this course was really for.

Further practice — apply it to your own repo

The most valuable thing you can do next is run this exact arc on your own project, where the stakes are real: /init a CLAUDE.md (with your real load-bearing gotchas), plan your next feature in plan mode, package the chore you do most often as a skill, give a reviewer subagent your gnarliest module, and try two independent changes in parallel worktrees. The devlog was the rehearsal; your repo is the performance.

Knowledge check

The final exam is below — 12 application questions drawn from all eleven chapters (passing score 9/12). It's the last thing between you and a completed course. Good luck.