Comprehensive Practice: Building and Deploying a Project from Scratch

📚 Series Navigation: The previous article 47 Voice Mode allowed you to replace "typing commands" with "speaking requirements," freeing up your hands. This article is the capstone project of the entire guide—it introduces no new features, but walks through a real-world project that is larger than the one in Chapter 39 and spans multiple sessions. We will mobilize CLAUDE.md, permissions, MCP, subagents, checkpoints, and Git all at once to trace a complete engineering flow from kickoff to delivery.

If you browse projects built with Claude Code and perform a rough audit, you'll realize: the ones that make you feel "this is truly worth the price" are never single-prompt, one-line edits; they are medium-sized projects spanning three to five sessions and utilizing four or five distinct capabilities.

Specifically, building an internal tool from scratch might take four sessions and about two and a half hours. Along the way, you might connect an MCP server to query docs, spawn a subagent for security reviews, and recover from code-breaking edits via checkpoints. Looking back at the clean Git history of seven commits, each explaining exactly what was changed, you realize that the tools you learned are not isolated tricks, but can be woven together into a single workflow.

Simply put, this is the gap between "knowing each feature" and "building a real project." Chapter 39 walked you through a minimal project—single-session, single-script, and purely local. This article expands the scope: the project is more complex, requires session handoffs, connects to external resources, spawns subagent clones, and gracefully rewinds when code breaks. Chapters 1-47 taught you how to play individual instruments; this article puts you in the conductor's seat to coordinate the entire orchestra.

Analogy: Conducting an orchestra to perform a symphony. You have practiced the violin, brass, and percussion—mastering each instrument individually. But knowing how to play each instrument is vastly different from coordinating them into a unified performance: you must know when each section enters, who plays the lead or support, and how to maintain the tempo. In this article, you are the conductor—with CLAUDE.md, permissions, MCP, subagents, checkpoints, and Git acting as your orchestra sections. We'll introduce them at the right moments to deliver a complete performance.

After reading this article, you will get:

• A complete map of a medium-sized project from scratch to delivery, clarifying where each feature is introduced and what task it resolves
• A workflow for multi-session handoffs: how to use --resume, specification documents, and checkpoints to safely split a large task across days or sessions
• Step-by-step commands and expected outputs for each key milestone, showing what to type, what to check, and where issues might arise
• A copy-pasteable real-world project (a command-line todo application with local storage, tests, and docs) connecting CLAUDE.md → Permissions → MCP → Subagents → Checkpoints → Git
• A comparison table between "toy practice" and "real-world projects," highlighting pitfalls that occur when scaling up

---

01 The Big Picture: Where Features Enter in a Medium-Sized Project

Before starting, let's look at the sheet music. A medium-sized project follows the same basic steps from scratch to delivery, but each step is heavier than in Chapter 39 and introduces new components.

This diagram maps a medium-sized project as a looping pipeline: six steps chain together sequentially, with the dashed line representing the key difference—real-world projects cannot be completed in a single session; once a round of verification finishes, you return to the planning stage in a new session to tackle features piece-by-piece. The straight path from Chapter 39 is bent into a cycle.

The two primary differences from Chapter 39 to remember:

• It spans multiple sessions. When a session's context window fills up, wrap it up (Chapter 19 explained how a cluttered workspace leads to mistakes) and transition to a fresh session. Managing "session handoffs safely" is a skill in itself.
• It mobilizes new tools. Single-script projects rarely require MCP or subagents, but they are standard in medium-sized projects—to fetch documentation, isolate tasks, or review code with a fresh model.

The official best practices state this clearly, forming the outline of this article:

Once you have a flow that works for a single Claude, scale your output through parallel sessions, non-interactive mode, and fan-out patterns.

Simply put: once you define a working flow, scale output using parallel sessions, non-interactive batch commands, and concurrent subagents—rather than iterating from scratch each time. This article demonstrates how to apply these techniques.

At the beginning of each section, we will note which previous chapter the step corresponds to, mapping features to implementation details. Keep the map in mind, and observe when each tool is introduced.

💡 Summary in one sentence: The basic structure of a medium-sized project remains "Kickoff → Planning → External Integrations → Task Delegation → Error Handling → Delivery," adding multi-session handoffs and tools like MCP and subagents; returning to the planning phase via the dashed line is standard for real-world projects.

---

02 Kickoff: Setting Up the Repository, CLAUDE.md, and Permission Baselines

Step 1—Kickoff. Corresponds to Chapters 12 and 18 (CLAUDE.md) and Chapter 20 (Permissions). For minor tasks, this is just "writing a few lines in CLAUDE.md," but for medium-sized projects, you must establish project guidelines and permission baselines simultaneously, as subsequent sessions inherit this foundation.

The project we will build: a command-line todo application (todo-cli)—allowing adding, listing, and checking off tasks, storing data locally in a JSON file, accompanied by unit tests and a README. It is larger than the single-file script in Chapter 39: spanning multiple files, requiring persistence, including tests, and split across sessions, while relying solely on the Python standard library so anyone can run it.

Step 1: Create repository structure and initialize Git

mkdir todo-cli && cd todo-cli && git init

Why is git init the very first step? Because it is your most reliable rollback safety net. While checkpoints (Chapter 37) can revert Claude's edits, they are separate from Git. A clean initial commit serves as a baseline you can return to no matter how edits drift—a rule highlighted in Chapter 39 that becomes more critical as projects scale.

Step 2: Start in the root directory and draft a concise CLAUDE.md

claude

Start the session and ask it to generate CLAUDE.md (for medium-sized projects, manually defining core rules is better than letting /init scan files, as there is no code to analyze yet):

Create a CLAUDE.md file:
1. This is a command-line tool relying solely on the Python standard library; do not import third-party dependencies.
2. Persist data to todos.json in the project root; all reads and writes must target this file.
3. Every feature must be accompanied by unittest tests; run python3 -m unittest to verify after modifications.
4. Commit messages should be in English, prefixed with feat: / fix: / docs: / refactor: / chore:.

Expected: Claude displays the proposed content and requests approval to write the file (Chapter 20 permissions). Once approved, a concise CLAUDE.md is created. Note that it is only about ten lines long. Let's repeat the guideline from the official docs:

Keep it concise. For every line, ask yourself: "Will deleting this cause Claude to make mistakes?" If not, delete it.

These four rules are constraints Claude cannot infer and will need consistently. In subsequent sessions, it automatically loads this manual, saving you from repeating "no third-party packages, run tests on change" in every session.

Step 3: Configure permission baselines—a critical step that separates larger projects from minor tasks

For small tasks, approving actions case-by-case works fine. But for larger projects editing multiple files across sessions, the official best practices warn: "after the 10th approval, you are not actually reviewing, you are just clicking accept." Establish a baseline on kickoff. Choose from these three approaches:

Approach	How to Use	Best Suited For
Permission Allowlists	Run /permissions to add trusted commands (e.g., python3 -m unittest, git status)	Safe commands run frequently, preventing repetitive prompts
Plan Mode	Toggle via Shift+Tab, or start with claude --permission-mode plan	Unfamiliar changes, or reviewing architecture proposals before coding
Auto Mode	Start with claude --permission-mode auto, where classifiers block only high-risk actions	When you trust the task context and want to bypass routine confirmations

A practical baseline for todo-cli: allowlist frequent commands like python3 -m unittest, git diff, and git status via /permissions first; toggle to Plan Mode via Shift+Tab for multi-file refactorings. Setting this baseline reduces approval noise by half—if omitted, confirming "should I run tests" can occur dozens of times, tempting you to disable confirmations entirely (which introduces real risks).

⚠️ Easing permissions is a double-edged sword—auto mode saves time but removes manual oversight. Chapters 20 and 21 detailed this trade-off: the more authority you delegate, the more you must rely on verification runs and checkpoints to catch errors.

💡 Summary in one sentence: Kickoff for a medium-sized project involves initializing Git for rollbacks, drafting a concise CLAUDE.md to define constraints, and configuring permission baselines via /permissions or Plan/Auto modes; configuring the permission baseline is the most critical preparation when scaling up.

---

03 Planning: Designing a SPEC and Planning Session Handoffs

With the baseline set, Step 2—Planning. Corresponds to Chapter 16 (Exploration), Chapter 20 (Plan Mode), and Chapter 19 (Context Management). This is where medium-sized projects diverge from minor tasks: instead of implementing code immediately after a brief prompt, you must design a specification document (SPEC.md) and tackle it in chunks across sessions.

Why is a SPEC document critical? When handling multiple features, vague ideas lead to implementation blocks—discovering unhandled boundaries or mismatched fields halfway through, forcing refactoring. The official best practices recommend: letting Claude interview you.

Step 1: Let Claude interview you to generate a SPEC

Toggle to Plan Mode (Shift+Tab) and prompt it:

I want to build a command-line todo application, todo-cli, storing data locally in JSON.
Use the AskUserQuestion tool to interview me in detail about the technical implementation, CLI design,
edge cases (e.g., empty lists, duplicate tasks, file corruption), and design trade-offs.
Avoid obvious questions; focus on difficult decisions I might have overlooked.
Once answered, write the complete specifications into SPEC.md.

Expected: Claude asks structured questions—"Should tasks support priority levels?", "If todos.json is missing, should it throw an error or initialize automatically?", "Does checking off a task delete it or flag it completed?" These are choices easily missed during manual planning. Once answered, it outputs SPEC.md, detailing commands, schemas, boundaries, and acceptance criteria. The official docs highlight the value of a SPEC:

The most useful specs are self-contained: they name the files and interfaces involved, state what is out of scope, and end with end-to-end verification steps.

When designing this tool, it often brings up choices you didn't consider: "If two tasks have identical descriptions, are they duplicates, and should we deduplicate them?" This prompts a design decision. Spending ten minutes answering interviews saves hours of refactoring later—an investment that pays off.

Step 2: Split the workload into session-sized chunks

Once the SPEC is ready, do not attempt to implement everything in a single session. As features expand, the session context window fills up, causing Claude to lose track or make mistakes (detailed in Chapter 19). Instead, split tasks into session-sized milestones based on the SPEC:

• Session 1: Scaffold—directory structure, todos.json reads/writes, add command, and tests
• Session 2: list and done commands, and tests
• Session 3: Edge cases (corrupt files, empty lists) and test coverage
• Session 4: README documentation, final validation, and delivery

Step 3: Session handoff practices

This is a critical practice for medium-sized projects. When a session milestone completes, how do you hand off to the next? Use two techniques:

• Wrap up with /clear, resume with --resume. When starting an unrelated task block, run /clear to reset context (the docs emphasize "frequent /clear between unrelated tasks"); to continue an active task thread, run claude --resume to reload the session.
• Use SPEC.md as the handoff log. Have the new session inspect SPEC.md and git log first; it catches up on progress in seconds—which is why specifications belong in files rather than chat histories: chats are cleared, files persist.

Here is a handoff prompt you can use at the start of every new session:

Read SPEC.md and git log first to catch up on our progress, do not modify any files yet.
Tell me what the next task is and if there are pending issues.

Skipping this handoff step easily causes issues—if the second session starts without reading the SPEC and you simply request "implement the list command," it might modify the JSON schema established in the first session. The mismatched formats waste development time. Maintain this discipline: always start new sessions with "read SPEC.md and git log first," letting it catch up autonomously.

The official documentation notes this convenient detail:

Claude Code saves conversations locally, so you don't have to re-explain context when tasks span multiple sessions.

While historical sessions are preserved, reloading massive chat histories consumes context window space, leading to degraded performance (Chapter 19). The SPEC file serves as a cleaner handoff anchor: a single file read in seconds updates the new session without cluttering the context window.

💡 Summary in one sentence: Planning involves letting Claude interview you to establish a SPEC.md, then splitting the workflow into session-sized blocks; clear context via /clear and hand off using SPEC.md and Git histories—chats are cleared, files persist.

---

04 External Integrations: Fetching Outside Resources via MCP

Once coding starts, you reach Step 3—External Integrations. Corresponds to Chapter 22 (MCP). While local scripts in Chapter 39 bypass this, medium-sized projects require it: you will eventually need to query external documentation, interface with databases, or open PRs.

When should you configure MCP? The official rule is simple:

When you find yourself copying data from another tool into your chat, connect a server.

A typical case when building todo-cli: when writing tests, you are unsure of the exact assertion methods in unittest. You search the browser manually and paste details into the prompt—this is the signal for MCP. Instead of manual copying, let the agent search directly.

Analogy: Plugging an ethernet cable into a local computer. Offline, a computer only accesses files on its local drive, requiring USB drives to import external data. Once connected online, it fetches resources directly. Claude behaves like that offline computer—only seeing local workspace files and terminal commands; MCP serves as the network connection. Once connected, it accesses external assets autonomously, whether that means documentation endpoints, databases, or GitHub APIs.

We will integrate the official documentation MCP server for this test. It is a hosted HTTP server requiring no authentication or local setup, serving as the most stable test server.

Step 1: Add the server (in host shell, not inside the claude session)

claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcp

Note: Adding this remote server requires active internet access. Adjust proxy settings if the connection is blocked.

Expected: Prints a confirmation line, e.g., Added HTTP MCP server claude-code-docs ....

Step 2: Verify connection status

claude mcp list

Expected: claude-code-docs displays ✓ Connected. A green checkmark confirms the connection; if it shows ✗ Failed to connect, check proxy routing.

Step 3: Direct the agent to query via this server

Query via the claude-code-docs server how subagents are defined in Claude Code,
their configuration paths, and the required schema fields.

Expected: Claude prompts you for approval on the first call to this server (Chapter 22 tool approval guidelines)—approve it. It returns details on subagents, with the tool output tagged with claude-code-docs. Seeing this tag confirms the data is fetched directly from the documentation endpoints instead of being hallucinated by the model.

In real-world projects, MCP use cases extend far beyond fetching docs. Observe these typical servers:

Target Resource	MCP Server	Capabilities Enabled
Repository issues/PRs	GitHub MCP	"Implement the feature described in issue #12 and open a PR"
Corporate Database	PostgreSQL or other SQL MCPs	"Query tasks created this month" (always use read-only roles in production)
Design Specs	Figma MCP	"Format CLI output to match this design layout"

Never forget the safety warning when integrating servers as projects scale (Chapters 21 & 22):

Verify that you trust each server before connecting it. Servers that fetch external content may expose you to prompt injection risks.

MCP servers run third-party code that Anthropic does not audit. Prefer official registries or trusted enterprise packages, and always connect databases using read-only accounts to minimize risks. Also keep the official note in mind: each connected server consumes context window memory. Run claude mcp remove claude-code-docs to clean up the doc server once the test completes.

💡 Summary in one sentence: Medium-sized projects benefit greatly from MCP—when you find yourself copying data manually, connect a server instead; prototype using the official docs server, utilizing GitHub, Figma, or databases in production while maintaining strict security checks.

---

05 Delegation: Spawning Subagents and Code Reviews

As files multiply, you reach Step 4—Delegation. Corresponds to Chapter 23 (Subagents) and Chapter 29 (Agent Teams). While skipped for minor scripts, these are the twin pillars that prevent the main session from bloating while maintaining code quality.

Using Subagents for Exploration to Prevent Context Bloat

By Session 3 of todo-cli, the codebase has expanded. Suppose you want to inspect "where file reading/writing occurs for todos.json." Do not ask the main agent to open and inspect each file—which imports file contents directly into the main context, leaving no room for coding (the workspace bloat warning from Chapter 19). Spawn a subagent to search instead:

Spawn a subagent to locate all functions where todos.json is read or written.
Return only a summary list of files, functions, and their purposes. Do not output code contents.

Expected: The subagent inspects files in its isolated context window, returning only a summary report back to the main chat. The official docs state this clearly:

Since context is your basic constraint, subagents are one of the most powerful tools available... they run in separate context windows and report back with a summary.

Analogy: Sending an intern to search the archives. You want the search results, not the physical filing cabinet dropped onto your desk. A subagent is that intern—digging through files inside its sandbox (isolated context), returning with a single summary page, keeping your workspace (main context) uncluttered.

Spawning a Fresh Model for Code Reviews

Once a feature is written, do not let the same Claude instance review its own code—it is biased towards its own design choices. In larger projects, always spin up a fresh context to critique edits. The official docs explain:

A reviewer running in a fresh subagent context only sees the diff and the criteria you gave it, not the reasoning that generated the change, so it evaluates the output on its own terms.

The easiest method is running the built-in /code-review command, which reviews the active diff inside a fresh subagent and lists defects:

/code-review

Alternatively, you can write custom review prompts, defining rules and boundaries:

Spawn a subagent to review the recent edits against SPEC.md. Verify that all specifications are met,
edge cases are tested, and no out-of-scope files were modified.
Highlight only critical defects; skip minor style preferences.

When building todo-cli, the reviewer subagent caught an unhandled edge case: assuming corrupt file states were resolved when it only caught missing files, neglecting malformed JSON syntax. This highlights the value of "fresh models"—reviewing changes without assumptions. However, avoid letting it get distracted; from the docs:

Tell the reviewer to only flag defects that affect correctness or stated requirements, treating the rest as optional.

Agent Teams (Chapter 29) represents an automated workflow for this step, though it is currently experimental and subject to changes. It coordinates multiple sessions around a shared task list—e.g., one implementing while another reviews. Start with manual subagent reviews; upgrade to agent teams once the repository scale demands concurrent loop automation.

💡 Summary in one sentence: When codebases expand, rely on two techniques—delegate search chores to subagents (isolating files to prevent context bloat), and verify quality via fresh model reviews (/code-review, ensuring the author doesn't audit their own work).

---

06 Error Handling: Rewinding Gracefully Instead of Patching Bugs

As projects expand, code-breaking edits become common, making Step 5—Error Handling—critical. Corresponds to Chapter 37 (Checkpoints). While introduced in Chapter 39, it is more important for larger projects: edits are more complex, drift easily, and you can no longer inspect the entire diff in a single glance.

The most common mistake: asking the agent to "fix this bug" on top of code that is already broken.

Do not stack patches. Writing edits on top of malformed code increases complexity and bloat—accumulating errors in the context history. The correct approach: rewind to a stable state, refine your instructions, and try again. Rewinding has two levels:

Rollback Level	Tool	Target State	Best Suited For
Light Rollback: Reverting recent edits	Checkpoints via /rewind or double-tapping Esc	Before the current file-edit block	Spotting a minor error immediately and wanting to undo
Heavy Rollback: Resetting to a stable commit	Git via git restore . (revert unstaged changes) or git reset --hard <SHA>	A stable commit logged previously	When the implementation has drifted and you want to retry from a clean slate

Light rollbacks are common: run /rewind to choose to revert code, conversation history, or both. The docs clarify a key detail: checkpoints only track files modified by Claude inside the current session; they do not track side effects from bash commands, nor are they a replacement for Git.

This is why you must commit frequently. Checkpoints only monitor edits in the current session; they cannot help when projects span sessions, run tests, or install packages—only Git tracks these dependencies. When building todo-cli, it is easy to drift: Session 3 requests JSON refactoring, but the agent edits three files and "optimizes" the add command, breaking logic. Because we committed at each milestone, running git reset --hard returned us to a stable state in seconds—relying solely on checkpoints would fail to resolve session gaps.

Once reverted, do not repeat the same prompt. Analyze why it drifted—usually due to missing constraints in the prompt (Chapter 15). Adding a constraint like "only refactor the two read/write functions; do not edit the add logic" makes the next run successful. Rewinding is not a failure; it is risk mitigation.

💡 Summary in one sentence: Code-breaking is common in larger repos—always revert to a stable baseline instead of stack-patching errors; use /rewind for minor edits, and Git for session-level resets; checkpoints are not Git replacements, so commit frequently.

---

07 Practice: Building and Delivering a Command-Line Tool

Let's walk through a reproducible capstone flow—building the first two milestones of todo-cli (scaffolding and the add/list commands), coordinating the six steps. It requires only Python 3 and its standard library.

Step 1: Kickoff (Section 02)

mkdir todo-cli && cd todo-cli && git init && claude

Once the session starts, write CLAUDE.md:

Create a CLAUDE.md file: use only Python standard libraries; persist data to todos.json in the project root;
each feature must have unittest tests, verified via python3 -m unittest; commit messages should be in English with a feat:/fix: prefix.

Expected: It displays the contents, prompts for confirmation, and writes a short CLAUDE.md. Next, add the test command to the allowlist: run /permissions and add Bash(python3 -m unittest*) under allow. Expected: Bash(python3 -m unittest*) appears in the list.

Step 2: Planning (Section 03)

Toggle to Plan Mode (Shift+Tab), asking it to outline the architecture first:

I want to build a todo-cli application: todo.py provides add "description" to add tasks,
and list to output all tasks (showing indices and completion status), storing data in todos.json.
Outline the file structure and implementation plan first, and wait for my go-ahead.

Expected: It proposes a plan—creating todo.py (containing JSON utility functions and argparse command parsing), and test_todo.py for testing. It pauses, waiting for your approval.

Step 3: Implementation and Diff Review (Section 02)

The plan looks good. Implement add and list, then write the corresponding unittest tests.

Expected: Claude creates todo.py and test_todo.py, prompting you with diff blocks at each step. Verify three things: ① it is implementing the add/list logic as planned; ② no third-party libraries are added (CLAUDE.md rules); ③ no out-of-scope files are touched. Approve once verified.

Step 4: Verification—Verify Edits Yourself (Universal Rule)

Run the test suite (pre-approved in the allowlist; it won't prompt):

python3 -m unittest

Expected Output (ending with OK):

...
----------------------------------------------------------------------
Ran 3 tests in 0.00s

OK

Execute commands manually to verify integration:

python3 todo.py add "Write Chapter 48"
python3 todo.py add "Verify Capstone"
python3 todo.py list

Expected Output (showing indices and completion status):

[1] [ ] Write Chapter 48
[2] [ ] Verify Capstone

Seeing tests pass and list commands behave as expected confirms this milestone works. Do not rely on promises; only verified execution confirms completion—a rule from Chapter 39 that becomes more critical as projects scale.

Step 5: Code Review via a Fresh Subagent (Section 05)

/code-review

Expected: The reviewer subagent audits the diff, listing recommendations. Resolve only critical bugs first; treat minor optimizations as optional.

Step 6: Delivery (Section 06 & Git)

Show which files were modified and display a summary diff.
Draft a commit message and commit the changes.

Expected: It runs git status and git diff to show modified files, drafts a commit message (e.g., feat: implement add and list commands), and requests approval to run git commit—triggering the permission prompt before editing history.

Step 7: Guard the Push Red Line

This wraps up the first milestone. However, remember the red line:

You can let the agent handle local commits, but the final step—git push—must be executed manually by you.

Before pushing commits to remote repositories (GitHub/GitLab), verify the modifications yourself and execute the command manually (Chapter 43). Keep the outbound keys in your own hands.

Running these steps coordinates "Kickoff → Planning → Scaffolding → Verification → Code Review → Commit → Remote Push" in a real-world project. Adding features like done or edge-case handling follows this same looping flow.

---

08 Comparison: Toy Practice vs. Real-World Projects

Scaling from simple scripts to larger codebases changes how you coordinate Claude. Here is a comparison of typical behaviors:

Milestone	❌ Toy Practice Shortcuts	✅ Real-World Project Workflows
Guidelines	Drafting a minimal CLAUDE.md	Configuring guidelines and permission baselines at kickoff for all sessions
Planning	Coding immediately after a brief prompt	Letting Claude interview you to establish a SPEC.md first, splitting work by milestones
Sessions	Pushing a single session until context window bloats	Clearing context via /clear between tasks, resuming via --resume, and using SPEC files
Integrations	Copying and pasting resources manually	Connecting MCP servers after verifying trust, utilizing read-only accounts
Quality	Letting the same instance review its own code	Spawning a fresh subagent reviewer (/code-review), separating author from audit
Errors	Stacking patches on top of malformed edits	Rewinding to clean states (/rewind or Git), committing frequently
Delivery	Leaving files unstaged or committing without diff audits	Auditing modified files → drafting commits → remapping git push manually

The takeaway: shortcuts allowed in toy files fail on production codebases—every omitted guard adds compounding complexity later. Moving from scripts to repositories often tempts developers to carry over loose shortcuts, leading to context bloat, patch stacking, and unreviewed commits. Process is not a drag on velocity; it is the infrastructure that allows you to scale.

A common question: "Does coordinating these steps slow down development?" On the contrary—maintaining this discipline is what allows you to delegate larger tasks safely. Skipping specs or validation runs seems fast initially, but merely shifts the timeline to troubleshooting and refactoring.

---

09 Summary

This article served as the capstone project—introducing no new features, but guiding you to coordinate the tools from Chapters 1-47 into a Capstone workflow.

Let's review the capstone workflow, mapping where each feature belongs:

Step	What It Does	Feature Link	Key Takeaway
Kickoff	Initialize repo, write CLAUDE.md, set permission baselines	12 / 18 / 20	Establish constraints and permissions once to govern all sessions
Planning	Interview specifications, split sessions	16 / 19 / 20	Chats are cleared; specifications belong in files to hand off
External	Connect MCP servers for docs, DBs, or APIs	22	Manual copying/pasting is the trigger to connect a server
Delegation	Delegate searches to subagents, review via fresh models	23 / 29	Isolate files to prevent main context bloat; separate coding from auditing
Error Handling	Revert changes cleanly upon breaking	37	Undoing recent edits via /rewind or resetting commits via Git
Delivery	Verify tests → commit edits → push manually	43 / 44	Automate local commits; execute remote pushes manually

You should now be able to: take a medium-sized prompt, structure the workspace via CLAUDE.md and permissions, design a SPEC.md during planning, split implementation across sessions, connect MCP servers, delegate file inspections to subagents, audit code using fresh reviews, revert drift cleanly, commit milestones, and push changes manually. Mastering this capstone loop combines these individual tools into a cohesive workflow.

The practical track is now complete—from the minimal script in Chapter 39 to this capstone flow, you have played the roles of both instrumentalist and conductor.

---

The next chapter 49 "Best Practices"—we walked through "how to do it"; the next moves a level higher: compiling lessons and habits into a checklist to optimize execution. Think about it: why do some developers complete workflows in three prompts while others require five rounds of refactoring? The difference lies in habits that are simple but impactful; we'll dissect them in the next chapter.

---

Recommended Reading

• Four Most Common Tasks: Exploring Codebases, Fixing Bugs, Refactoring, Writing Tests
• CLI Reference Manual: Commands and Flags
• Plugins: Packaging Loose Configurations in One Command