Putting It All Together
A guided end-to-end exercise using everything you've learned
What you'll do
The Challenge
You're going to build a feature using everything from this course. Start to finish. Workspace setup, agent team, contract-first spawning, observability, lazygit review. One continuous workflow.
The feature: add a /health endpoint to an API project that returns system status, uptime, and dependency checks. It's realistic enough to exercise all the coordination patterns you've learned, and scoped tightly enough to complete in a single session.
Three distinct domains — a health service that gathers data, a route handler that exposes it, and tests that verify the behavior — make this a natural fit for an agent team. Each domain has clean boundaries. The agents can work in parallel once the contract is established. That's exactly the scenario this course was built for.
Don't adapt the feature to a different project yet. Follow the workflow as written first. Once you've done it once end-to-end, you'll have the muscle memory to apply the same pattern to any feature on any codebase.
Step 1: Launch Your Workspace
Modules 2 + 4
Start your tmuxinator workspace
If you completed Module 4 and have a workspace configured, start it now:
tmuxinator start claude-workspaceIf you don't have a tmuxinator config yet, build the layout manually. You need three panes in a single window:
# New session
tmux new -s capstone
# Split into three panes: Claude Code, lazygit, and a free agent pane
Ctrl+B then " # horizontal split (top/bottom)
Ctrl+B then % # vertical split on bottom paneBefore you move on, verify your layout:
- Pane 1 (large, top or left) — this is where you'll run Claude Code
- Pane 2 — run
lazygithere - Pane 3 — open space for watching agents or running test commands
Navigate between panes with Ctrl+B then an arrow key. Confirm each pane responds before continuing.
Step 2: Plan Before You Build
Module 5
Ask Claude to plan the feature in plan mode
Switch to your Claude Code pane. Before spawning any agents, ask Claude to plan the work:
Plan a /health endpoint that returns JSON with: server uptime,
database connectivity status, and current timestamp. We need a
route handler, a health service, and a test.Read the plan. Claude will likely identify the same three domains you already know about. This is the moment to make a deliberate decision: single agent or team?
- Three distinct domains with clean interfaces → agent team
- One small file with no dependencies → single agent is faster
For this feature: three distinct domains. Agent team it is.
Confirm the plan covers all three deliverables: the service module, the route handler, and at minimum one test file. If Claude's plan is missing any of these, ask for it explicitly before moving on.
Step 3: Enable Agent Teams and Spawn with Contract-First
Modules 6 + 10
Spawn the team using the contract-first pattern
First, verify agent teams is enabled in your Claude Code settings. Then craft your spawn prompt. This is the most important prompt in the whole exercise — get it right:
Create an agent team to implement this health endpoint. Spawn
three teammates:
- HealthServiceAgent: builds the service module (data layer) —
uptime calculation, database ping, timestamp. This agent defines
its contract first: what functions it exports and what they
return. It writes this contract to health-service-contract.md
before writing any implementation code.
- RouteHandlerAgent: builds the route handler (API layer) —
registers the /health route, calls the service, formats the
JSON response. This agent WAITS until HealthServiceAgent has
written health-service-contract.md, then imports from the
service using exactly that interface.
- TestAgent: writes tests covering the route and service. This
agent also waits for the contract before writing tests, so
it tests the real interface, not an assumed one.
HealthServiceAgent goes first. RouteHandlerAgent and TestAgent
begin only after the contract file exists.Watch your tmux panes. As Claude spawns the team, new activity should appear. Each agent gets its own context.
If you have a popup binding configured (Ctrl+B g for lazygit, etc.), this is a good moment to use it — you can check lazygit without leaving your Claude pane.
The health-service-contract.md file is a coordination artifact. It turns an implicit dependency ("the route handler needs the service to exist") into an explicit one ("the route handler waits for this file"). Without it, RouteHandlerAgent might start writing import { getHealth } from './health-service' before HealthServiceAgent decides what that function is called. That's how integration failures happen. The contract prevents it.
Step 4: Monitor the Build
Modules 7 + 8 + 11
Watch the team work using your observability tools
Don't just wait. This is where your tmux skills pay off. As the agents run:
Check the task list:
Ctrl+TYou should see tasks assigned to each agent. If any agent's task shows no progress after a couple of minutes, switch to its pane and check what it's doing.
Navigate panes to watch progress:
Ctrl+B then arrow keysMove to the pane where HealthServiceAgent is running. Watch for the moment it writes health-service-contract.md. That's the coordination handoff — the other two agents can't productively start until this happens.
Scroll back if you miss something:
Ctrl+B then [ # enter scroll mode
Arrow keys / Page Up / Page Down to scroll
q # exit scroll modeWatch for context usage: If any agent is approaching 83% context, it should wrap up its current work and commit before continuing. If you notice an agent stalling near that threshold, prompt it to commit and summarize.
The contract handoff is the key moment in this exercise. When you see RouteHandlerAgent or TestAgent reference the contract file and start working, the coordination is working correctly.
Step 5: Review with lazygit
Module 3
Inspect every agent commit before you accept the work
Switch to your lazygit pane (or use the popup if you configured one). The Commits panel should show individual commits from each agent.
Navigate to the Commits panel:
Number keys 1-5 cycle through panels
Enter on a commit to drill into its diff
Tab to move between the commit list and the diff viewFor each agent's commits, you're checking three things:
- Service exports match route imports — open the service commit and the route commit side by side (in separate panes if needed). The function names and signatures must match exactly.
- Tests cover the real interface — the test file should import from the actual service module using the same export names. If the tests are mocking a different interface than what was built, they'll pass but prove nothing.
- Commit history is clean enough to understand — you should be able to read the commit messages and reconstruct what happened. If it's a mess of "wip" commits, use interactive rebase to clean it up.
If you need to clean up commits:
i # interactive rebase from lazygit Commits panel
# squash wip commits, reword unclear messagesTake your time here. The review step is where you catch integration problems before they're merged.
Step 6: Validate and Iterate
Run the tests and handle whatever comes back
Switch to your free pane and run the tests:
# Exact command depends on your project's test runner
npm test
# or
bun test
# or
pytestFirst-pass results rarely come back clean. That's expected. The question is whether you can see why something failed — and you can, because you have the full commit history, the contract file, and the agent output available.
Common first-pass failures and how to address them:
- Import path is wrong — look at the route handler commit in lazygit. The path it's importing from may not match where the service agent wrote the file. Fix the path in your Claude pane.
- Function signature mismatch — the contract file is your reference. If the implementation drifted from the contract, ask Claude to bring one of them into alignment.
- Tests assume a different response shape — if the tests check for
{ status: "ok" }but the route returns{ healthy: true }, one of them needs to change. Check the plan from Step 2 to determine which is correct.
For targeted fixes, you don't need a full team — a single focused prompt to Claude usually handles these. Spawn a small fix team only if the issue is structural enough that multiple files need to change together.
The reason observability and lazygit matter is that iteration is guaranteed. The goal isn't to get it right on the first pass — it's to be able to diagnose what went wrong and fix it quickly. That's what this course built: the ability to see what's happening and act on it.
What You Just Did
Here is every module you applied, in order:
What's Next
This course covered tmux as your agent control center — the workspace, the tools, and the workflows that make multi-agent development practical. You have everything you need to run agent teams on real projects.
To go deeper: building custom skills, writing your own slash commands, and designing agent orchestration patterns that encode your team's best practices into reusable artifacts — that's the next layer. We're building a course for exactly that.
Claude Skills Course
Build custom skills, slash commands, and agent orchestration patterns that encode your team's best practices into reusable, shareable artifacts. Everything in this course — packaged as skills you can invoke with a phrase.
Launching soon — check back at the course overview.
In the meantime, experiment. Run agent teams on your real projects. The workflow you practiced in this capstone works for any feature with multiple independent domains — which is most of them. The more you use it, the more natural it becomes.
The agents are ready when you are.