Capstone: ship a feature end to end with agents

This lesson is short to read and long to do. You’ll ship one real feature in your own repo, using every habit from the course, and keep notes as you go.

Pick something you’d normally spend half a day to two days on. Small enough to finish this week, real enough that someone will use it.

The run, end to end

1. 📏Size & briefModules 2 and 3
2. ↓→
3. 🗺️Review the planSteer before code
4. ↓→
5. 🧪Build test-firstModule 4 loop
6. ↓→
7. 🔍Review & PRYou own it
8. ↓→
9. 📈Measure & shareFeed the team

↺ Surprises go back to the brief, not into a longer chat

Step by step

1. 1

   15 min

   Pick and size the feature

   Write one sentence of user value. If it needs more than three or four agent-sized tasks, cut scope or split it (Module 3).

2. 2

   10 min

   Check the context

   Is your instruction file current? Which files, docs and examples will the agent need? Note them in the brief (Module 2).

3. 3

   20 min

   Write the brief

   Goal, constraints, acceptance criteria you can check, what not to touch, and the review guide you want back.

4. 4

   15 min

   Review the plan

   Ask for a plan before code. Correct it once in writing. If the plan is wrong twice, your brief is the problem.

5. 5

   Varies

   Build test-first

   Tests that encode the acceptance criteria first, then implementation, with types, lint and tests running each step (Module 4).

6. 6

   30 min

   Self-review

   Use the fixed review order. Fix or re-brief. Split the branch if it grew too big to review in one sitting.

7. 7

   10 min

   Open the PR

   Use the team template: how it was built, where to look, what isn't verified (lesson 6.2).

8. 8

   15 min

   Retro and promote

   What did you correct twice? Promote it up the ladder (lesson 6.1). Log time and rework for your metrics (lesson 6.3).

If you want to go further, split the build into two independent slices and run them in parallel, as in Module 5. Only do it if the slices really don’t touch the same files.

Your capstone brief

Copy this, fill every blank, and don’t start the agent until each line has a real answer.

FEATURE: {one sentence of user value}

CONTEXT
- Read first: {files, docs, an existing example to imitate}
- Conventions: follow the repo instruction file.

ACCEPTANCE CRITERIA (each one becomes a test)
1. {observable behaviour}
2. {observable behaviour}
3. {edge case or error path}

CONSTRAINTS
- Don't touch: {areas out of scope}
- No new dependencies without asking.

PROCESS
- Propose a plan first and wait for my OK.
- Write failing tests for the criteria, then implement.
- Run {test, typecheck, lint commands} before saying you're done.

WHEN DONE
- Files grouped as core / tests / interfaces / mechanical.
- Decisions I didn't specify, and what you did NOT verify.

Check your judgment

🧠 Capstone decisions

Score: 0 / 4

1. 1. The agent's plan touches a module you didn't mention in the brief. What now?

   Let it proceed, it probably knows bestAsk why, then either add it to the brief or rule it out explicitlyStop and write the feature by handApprove and review it later in the diff

   Plan review is the cheapest place to catch scope creep. Decide now, in writing, so the build doesn't drift.

2. 2. Halfway through, you've corrected the same mistake three times in chat. Best move?

   Keep correcting, it's almost doneStart a fresh session with the correction written into the briefSwitch to a bigger modelTurn off the tests so it can finish

   Repeated corrections mean the context is working against you. A clean restart with a better brief is usually faster (Module 2).

3. 3. Tests pass, but one existing test's expected value was changed. What do you do?

   Merge, CI is greenFind out whether the requirement changed; if not, revert the test and fix the codeDelete the testMention it in the PR and let the reviewer decide

   A changed expectation is the classic way an agent makes red go green. You own the answer before anyone reviews.

4. 4. The feature shipped. What's the last step of the capstone?

   Close the ticket and move onRecord time and rework, and promote one lesson into team conventionsWrite a blog post about itDelete the brief

   The feature is half the value. The other half is what the team keeps: a better instruction file, a shared prompt, a data point.

↺ Try again

Before you finish the course

✅ Capstone done

0 / 5 completed

• I shipped a real feature using a written brief with testable acceptance criteria.
• I reviewed the agent's plan before any code was written.
• The feature was built test-first, and I self-reviewed the full diff.
• The PR used the team template and passed a human review.
• I promoted at least one lesson into team conventions and logged time and rework.

↺ Reset