Module 10: Capstone Project

Time to put everything together. This capstone walks you through implementing a real feature end-to-end using the full Claude Code toolkit. Pick your stack, follow the workflow, and reflect on the experience.

No new concepts here, just the ones you've already learned, applied in sequence on a real task. The goal is to internalize the full cycle so it becomes second nature.

---

The Workflow

The capstone follows the full cycle from the course, mapped to the PDCA (Plan-Do-Check-Act) improvement loop:

1. Set Up: CLAUDE.md, project context
2. Plan: Plan mode exploration and design (PDCA: Plan)
3. Implement: Exit plan mode, implement with verification-first prompting (PDCA: Do)
4. Test: Run tests, verify loop, fix failures (PDCA: Check)
5. Simplify: /simplify to clean up (PDCA: Check)
6. Review & Commit: git diff, review, commit (PDCA: Act)
7. PR: Create a pull request documenting the work

Each step has a built-in checkpoint. You plan before writing, test before reviewing, simplify before committing. No step assumes the previous one was perfect.

---

The Task: Add a Feature to an Existing Project

Pick any project you're currently working on (or have recently worked on) and add a meaningful feature. The best capstone task has these characteristics:

• Touches multiple layers: not just one file, but a change that spans routing, logic, data, and UI (or the equivalent layers in your stack)
• Requires tests: the feature should be testable, and writing tests should be part of the implementation
• Exercises the full PDCA cycle: complex enough to benefit from planning before implementation, but scoped enough to finish in one session
• Has clear acceptance criteria: you can describe what "done" looks like before you start

Examples: add a new API endpoint with validation and tests, implement a feature that integrates with an existing service, add a reporting view that aggregates data from multiple sources.

Don't have a project ready?

Scaffold one first. Ask Claude Code: "Create a minimal project with a basic feature I can extend." Then use that as your starting point.

---

Step-by-Step Guide (All Tracks)

The steps below apply regardless of which track you chose. The prompts use placeholders; replace them with your track's specifics.

Step 1: Set Up Project Context

# If you don't have a CLAUDE.md yet:
/init

# Review and enhance the generated CLAUDE.md with:
# - Build/test commands
# - Architecture overview
# - Key patterns and conventions

A good CLAUDE.md is the foundation. If Claude doesn't know how to run your tests or where your code lives, every step after this gets harder.

Revisit Module 2

If your CLAUDE.md feels thin, go back to Module 2: Project Context and apply the patterns there. The capstone will expose any gaps, so better to fill them now.

Step 2: Plan (Plan Mode)

# Enter plan mode
/plan

# Explore the codebase
What is the current project structure? How are [features/endpoints/services] organized?

# Request a plan
I want to [describe your track's task]. Create a detailed plan including:
- Files to create or modify
- Architecture decisions
- Test strategy
- Any potential risks or gotchas

Review the plan. Ask questions. Push back on anything you disagree with. Refine until you're confident in the approach.

Don't skip planning

It's tempting to jump straight to implementation, especially for a task that feels simple. Resist that urge. The planning step is where you catch architectural mistakes that are expensive to fix later. A five-minute plan saves a thirty-minute revert.

Step 3: Implement (Normal Mode)

# Exit plan mode (Shift+Tab)

# Create a checkpoint before you start
git add -A && git commit -m "checkpoint: before capstone feature"

# Implement with verification-first prompting
Implement [the feature] as planned. After each file change, run the relevant tests.
ONLY modify the files we discussed in the plan.

Review each diff as Claude proposes changes. This is where the discipline from Module 6 pays off. You should be reading diffs, not rubber-stamping them.

Step 4: Test

Run the full test suite. Fix any failures.

Watch the verify loop in action. Claude reads failures, fixes code, re-runs tests. If it gets stuck in a loop (fixing the same test repeatedly), intervene. The test expectation might be wrong, or the plan might need revisiting.

Step 5: Simplify

/simplify

Let Claude review the changes for code quality: redundant logic, unclear naming, unnecessary complexity. This is the self-review step before you commit.

Step 6: Review & Commit

git diff          # Review all changes, every line
git add -A && git commit -m "feat: add [feature description]"

Read the full diff. Not just the files Claude created, but anything it touched. Look for unintended changes, leftover debug code, or patterns that don't match your project conventions.

Step 7: Create a PR (Optional)

Create a pull request for these changes with a clear description
of what was added and why.

If you're working on a real project, this closes the loop. If you're practicing on a scratch project, writing the PR description is still valuable. It forces you to articulate what changed and why.

---

Document Your Experience

As you work through the capstone, keep notes on:

• Prompts that worked well: what made them effective?
• Prompts that needed iteration: what was missing?
• Checkpoints taken: when did you commit, and did any save you?
• Review decisions: did you reject any changes? Why?
• Context management: did you use /compact or /clear? When and why?
• Surprises: anything unexpected, good or bad?

These notes are more valuable than the code you produce. The capstone feature itself is throwaway. The workflow habits stick.

---

Reflection Questions

After completing the capstone, sit with these:

1. How did Plan Mode change your approach compared to diving straight in? Did the plan survive contact with implementation, or did you need to adjust?
2. Did verification-first prompting catch issues earlier than you expected? Were there failures you wouldn't have caught by reading the code alone?
3. What would you put in CLAUDE.md differently next time? Did Claude struggle with anything you could have prevented with better project context?
4. Where did Claude excel, and where did you need to intervene? Understanding the boundary is the most important thing you can take from this course.
5. How would you explain the PDCA cycle to a skeptical colleague? Not the theory, the concrete workflow you just used.

These aren't academic questions

If you're doing this capstone as part of a team or course, discuss your answers. The most useful insights come from comparing experiences: where one person's prompts worked and another's didn't, and understanding why.

---

Bonus Challenges

If you finish early or want to push further:

• Use a subagent: Ask Claude to explore a related module in parallel while implementing your feature. Compare the results.
• Set up a hook: Add a post-edit hook that auto-formats code after every file change (e.g., Prettier, Black, or dotnet format).
• Create a skill: Build a /fix-issue skill for your project that reads a GitHub issue and implements a fix.
• Try /batch: Apply a consistent change across multiple files (e.g., add error handling to all endpoints, or update imports across a module).
• Try headless mode: Run claude -p "Generate a changelog for the last 10 commits" > CHANGELOG.md and see how it handles the task without interaction.

Each bonus maps to a course module

Subagents, hooks, skills, batch operations, headless mode: these are all covered in earlier modules. The bonus challenges are a chance to apply them in a real context instead of isolated exercises.