Module 8: Project — Complete Multi-Agent System

5. Retrospective — Analysis, Optimization, and Closing the Guide

5. Retrospective — Analysis, Optimization, and Closing the Guide

Description

The execution finished. The team of 5 agents completed the task board, the hooks validated each step, the SDK generated metrics, and you have a complete execution report. Now it's time to do what every professional team does after a sprint: a retrospective.

This capsule doesn't have traditional exercises. It's a structured retrospective where you analyze what worked, what didn't, where the bottlenecks were, and what you'd change for the next execution. It also closes the complete guide — it connects what you learned with guides #10 and #11 of the path, and leaves you with a concrete action plan.

Part 1: Results Analysis

What each agent produced

After the execution, review each agent's deliverables:

Backend Agent:

echo "=== Backend Deliverables ==="
find src/api src/models src/services src/schemas src/types -type f 2>/dev/null

Expected:

  • src/schemas/task.py — Pydantic models (TaskCreate, TaskUpdate, TaskResponse)
  • src/api/routes/tasks.py — 5 CRUD endpoints
  • src/types/task.ts — Shared types for frontend
  • Possibly: src/services/task_service.py — Business logic layer

Analysis questions:

  • Are the schemas complete? Any missing fields?
  • Do the endpoints follow the pattern defined in CLAUDE.md?
  • Are the types published in src/types/ exact with respect to the schemas?
  • Is the business logic in services or in the route handlers?

Frontend Agent:

echo "=== Frontend Deliverables ==="
find src/components src/pages src/hooks -type f 2>/dev/null

Expected:

  • src/components/TaskList/index.tsx — Task list
  • src/components/TaskCard/index.tsx — Individual task with toggle
  • src/components/CreateTaskForm/index.tsx — Creation form
  • src/hooks/useTasks.ts — Hook for data fetching (possible)

Analysis questions:

  • Do the components import types from src/types/ or define them inline?
  • Do they have loading, error, and empty states?
  • Are the props typed with TypeScript interfaces?
  • Do the field names match what the backend published?

Testing Agent:

echo "=== Testing Deliverables ==="
find tests -type f -name "*.py" 2>/dev/null

Expected:

  • tests/test_tasks_api.py — Endpoint tests
  • tests/test_components.py — Component tests (if applicable)
  • tests/conftest.py — Shared fixtures (if it didn't exist)

Analysis questions:

  • Do the tests cover happy path, error cases, and edge cases?
  • Do they use fixtures or hardcode data?
  • Do all the tests pass?
  • Are there tests that are trivial (a test that validates nothing new)?

Docs/Review Agent:

echo "=== Docs Deliverables ==="
find docs -type f 2>/dev/null

Expected:

  • docs/api/tasks.md — API documentation
  • Quality review integrated into the team lead's final report

Analysis questions:

  • Is the API documentation complete? (endpoints, schemas, examples)
  • Did the quality review identify real issues?
  • Are the review's recommendations actionable?

Deliverables matrix

Fill in this matrix with your real results:

| Agent             | Files created    | Files expected     | Match? |
|-------------------|------------------|--------------------|--------|
| backend-agent     |                  | 3-5                |        |
| frontend-agent    |                  | 3-4                |        |
| testing-agent     |                  | 2-3                |        |
| docs-review-agent |                  | 1-2                |        |
| TOTAL             |                  | 9-14               |        |

Part 2: Performance Analysis

Dashboard metrics

If you ran the monitor (capsule 04), review the dashboard:

python scripts/monitor/team-monitor.py --summary

Analyze:

1. Which agent took the longest?

Typically the backend-agent or the testing-agent. The backend-agent has more tasks (schemas, types, endpoints, error handling). The testing-agent takes time because it runs the test suite in addition to writing it.

2. Which agent was the most efficient?

Efficiency = output produced / time invested. An agent that creates 3 files in 15 seconds is more efficient than one that creates 1 file in 20 seconds.

3. Was there idle time?

Review the activity timeline. If the frontend-agent had long periods without activity while waiting for the backend, there's an opportunity for optimization (add frontend tasks independent of the backend).

4. How much was the coordination overhead?

The team lead uses turns to read, plan, assign, and forward context. That time is overhead. If the team lead used 30 turns and the agents used 60 in total, the coordination overhead is ~33%.

Performance analysis template

PERFORMANCE ANALYSIS
═══════════════════

Total execution time:     ___________
Total agent time:         ___________
Coordination overhead:    ___________%

Agent Rankings (by total time):
1. _____________ — _____s (___ tasks)
2. _____________ — _____s (___ tasks)
3. _____________ — _____s (___ tasks)
4. _____________ — _____s (___ tasks)

Most efficient agent:     _____________
Bottleneck agent:         _____________
Most idle agent:          _____________

Parallelism achieved:
- Tasks that ran in parallel: ___/___
- Potential parallelism:      ___/___
- Parallelism utilization:    ___%

Part 3: Conflict Analysis

Types of conflicts

Review the execution and document each conflict that occurred:

1. Type Mismatches

Did the types the backend published match exactly what the frontend consumed?

Type conflict found:
- Backend published: status as string enum ("pending" | "completed")
- Frontend interpreted: status as boolean
- Resolution: team lead instructed the frontend-agent to use the backend's type
- Root cause: insufficient context forwarding

2. Naming Inconsistencies

Were the field, function, and file names consistent?

Naming inconsistency:
- Backend uses: created_at (snake_case)
- Frontend uses: createdAt (camelCase)
- Resolution: the types in src/types/ use camelCase (JS convention)
- Root cause: CLAUDE.md didn't specify the naming convention for src/types/

3. Boundary Violations

Did any agent touch files outside its territory?

Boundary violation:
- frontend-agent created a helper in src/utils/api.ts
- src/utils/ isn't in its defined territory
- Resolution: move to src/hooks/ or add src/utils/ as shared territory
- Root cause: the agent file didn't include src/utils/ in the boundaries

4. Dependency Violations

Did any task execute before its dependencies completed?

Dependency violation:
- T7 (CreateTaskForm) was assigned before T3 (endpoints) finished
- The frontend-agent didn't have the endpoint URLs
- Resolution: team lead reassigned with full context
- Root cause: team lead didn't verify dependencies before assigning

Conflict analysis template

CONFLICT ANALYSIS
═════════════════

Type mismatches:      ___
Naming issues:        ___
Boundary violations:  ___
Dependency violations:___

Most problematic area:    _____________
Root cause pattern:       _____________
Suggested fix:            _____________

Part 4: Optimization

10 concrete optimizations

Based on your analysis, identify what you'd change. Here are the 10 most common optimizations:

1. Improve the team lead's context forwarding

If the frontend-agent didn't receive enough context:

# Add to team-lead.md:
## Context Forwarding Checklist (MANDATORY)
Before assigning ANY frontend task that depends on backend:
□ Endpoint URLs with full paths
□ Request schemas with ALL fields and types
□ Response schemas with ALL fields and types
□ Error response format with example
□ File path of published types (exact path)
□ Authentication requirements (if any)

2. Add independent frontend tasks

If the frontend-agent was idle:

Add to the task board:
- T2b: "Create reusable Button, Input, Card components" (no dependencies)
- T2c: "Create useFetch custom hook" (no dependencies)
- T2d: "Create base CSS/theme variables" (no dependencies)

3. Reduce maxTurns where it's safe

If the agents finish with turns to spare:

# Reduce from 25 to 20 for fast agents
maxTurns: 20  # frontend-agent, docs-review-agent

# Keep high for agents that run commands
maxTurns: 30  # testing-agent (runs pytest)

4. Specify naming conventions in CLAUDE.md

If there were naming inconsistencies:

## Naming Conventions
- Python: snake_case for variables, functions, files
- TypeScript: camelCase for variables/functions, PascalCase for components
- src/types/: camelCase (JavaScript convention — frontend consumes these)
- API endpoints: kebab-case in URLs, snake_case in JSON bodies

5. Add a boundary enforcement hook

If there were territory violations:

#!/bin/bash
# pre-tool-boundary.sh
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty')
FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.path // empty')
AGENT=$(echo "$INPUT" | jq -r '.agent_name // empty')

if [[ "$AGENT" == "frontend-agent" ]]; then
  if echo "$FILE" | grep -qE "^src/(api|models|services|schemas)/"; then
    echo "BLOCKED: frontend-agent cannot modify $FILE"
    exit 2
  fi
fi

if [[ "$AGENT" == "backend-agent" ]]; then
  if echo "$FILE" | grep -qE "^src/(components|pages|hooks|styles)/"; then
    echo "BLOCKED: backend-agent cannot modify $FILE"
    exit 2
  fi
fi

exit 0

6. Make the task board more granular for backend

If the backend-agent took a long time:

Instead of:
  T3: "CRUD endpoints" (one task for 5 endpoints)

Split into:
  T3a: "POST /api/tasks endpoint"
  T3b: "GET /api/tasks and GET /api/tasks/{id} endpoints"
  T3c: "PUT /api/tasks/{id} endpoint"
  T3d: "DELETE /api/tasks/{id} endpoint"

7. Add pre-checks to the testing-agent

If the tests failed for lack of infrastructure:

# Add to testing-agent.md:
## Before Writing Tests
1. Verify the source files exist (Glob)
2. Verify the project can import the modules (Bash: python -c "import src.api")
3. Check if conftest.py exists; create if not
4. Check if pytest is installed (Bash: python -m pytest --version)

8. Consolidate the quality review

If the docs-review-agent didn't produce a useful review:

# Add to docs-review-agent.md:
## Review Template (MANDATORY)
Your review MUST include ALL of these sections:
1. Files Reviewed (list with quality grade A-D)
2. Critical Issues (must fix before merge)
3. Warnings (should fix soon)
4. Suggestions (nice to have)
5. Positive Patterns (what was done well)
Do NOT produce generic reviews. Be specific with file:line references.

9. Improve the team lead's error messages

If the error messages weren't useful:

# Add to team-lead.md:
## Error Reporting Format
When reporting errors to the user:
1. WHAT failed (task ID, agent, specific error)
2. WHY it failed (dependency missing, timeout, boundary violation)
3. IMPACT (which downstream tasks are blocked)
4. RECOMMENDATION (retry with X, manual intervention needed, skip)

10. Add cost metrics to the SubagentStop hook

If you want cost tracking:

#!/bin/bash
# subagent-stop-log-v2.sh
INPUT=$(cat)
AGENT=$(echo "$INPUT" | jq -r '.agent_name // "unknown"')
DURATION=$(echo "$INPUT" | jq -r '.duration_ms // 0')
COST=$(echo "$INPUT" | jq -r '.cost_usd // 0')
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

LOG_DIR="logs/agents"
mkdir -p "$LOG_DIR"

echo "[$TIMESTAMP] Agent: $AGENT | Duration: ${DURATION}ms | Cost: \$${COST} | Status: completed" \
  >> "$LOG_DIR/agent-activity.log"

exit 0

Part 5: Retrospective Template

Use this template to document your retrospective. You can save it in docs/retrospective.md:

# Multi-Agent System Retrospective

**Date:** [date]
**Feature:** [what was implemented]
**Team:** 5 agents (team lead + frontend + backend + testing + docs/review)

## What Went Well (Liked)
1. [something that worked well]
2. [something that worked well]
3. [something that worked well]

## What Was Challenging (Learned)
1. [something that was hard but you learned from]
2. [something that was hard but you learned from]
3. [something that was hard but you learned from]

## What Didn't Work (Lacked)
1. [something that didn't work]
2. [something that didn't work]
3. [something that didn't work]

## What to Change (Longed For)
1. [something you'd change for next time]
2. [something you'd change for next time]
3. [something you'd change for next time]

## Metrics
- Total execution time: ___
- Tasks completed: ___/___
- Tasks blocked: ___
- Agent with most time: ___
- Agent with most tasks: ___
- Total cost (estimated): ___

## Action Items for Next Run
- [ ] [concrete action]
- [ ] [concrete action]
- [ ] [concrete action]
- [ ] [concrete action]

The 4Ls methodology

This template uses the 4Ls methodology (Liked, Learned, Lacked, Longed For), which is standard in agile retrospectives:

  • Liked — What worked well and you want to keep?
  • Learned — What did you learn during the execution?
  • Lacked — What was missing or didn't work?
  • Longed For — What do you wish had existed or worked differently?

Part 6: Planning the Next Execution

Improvements checklist for V2

Based on your retrospective, create a plan for the next execution of the system:

V2 IMPROVEMENTS CHECKLIST
══════════════════════════

Agent Files:
- [ ] Update the frontend-agent's boundaries (add src/utils/ if necessary)
- [ ] Add explicit naming conventions to the team lead
- [ ] Reduce maxTurns for fast agents
- [ ] Add pre-checks to the testing-agent

Task Board:
- [ ] Add 2-3 frontend tasks independent of the backend
- [ ] Split large backend tasks into subtasks
- [ ] Adjust dependencies based on the real flow

Hooks:
- [ ] Add a boundary enforcement hook
- [ ] Add cost metrics to the SubagentStop hook
- [ ] Adjust the PreToolUse hook's sensitivity (if it was too strict)

CLAUDE.md:
- [ ] Add naming conventions for src/types/
- [ ] Add Architecture Decision Records
- [ ] Clarify ownership of shared directories

Monitoring:
- [ ] Add cost tracking to the dashboard
- [ ] Add completion notifications
- [ ] Add comparison between executions

Iteration patterns

Iteration 1 (what you did): 5 agents, 10 tasks, basic CRUD feature.

Iteration 2 (improved): The same 5 agents with improved system prompts, boundary enforcement hooks, an optimized task board with additional parallel tasks.

Iteration 3 (expanded): 6 agents (add security-agent), 12 tasks, more complex feature (CRUD + auth + rate limiting).

Iteration 4 (production): Published plugin, CI/CD pipeline (Guide #10), integrated security audit (Guide #11), execution in automatic CI.

Part 7: Connection to the Rest of the Path

What you completed

You've finished Guide #9: Advanced Claude Code Workflows. Here's everything you mastered:

Guide #9 — Complete ✅
├── M1: Custom Subagents ───────── Create agents with their own identity
├── M2: Agent Memory ───────────── Memory scopes for shared context
├── M3: Parallel Delegation ───── Frontend + backend simultaneously
├── M4: Agent Teams ────────────── Team lead + task board + dependencies
├── M5: Plugins ────────────────── Package and distribute configurations
├── M6: Hooks + SDK ────────────── Quality gates + programmatic execution
├── M7: Remote + CLAUDE.md ────── Governance + remote approvals
└── M8: Capstone Project ───────── Functional multi-agent system

Guide #10: Claude Code in CI/CD Pipelines

The next guide takes what you built here and integrates it into continuous integration pipelines:

  • Headless SDK in GitHub Actions — The Python scripts you wrote in M6 and M8 run as CI steps
  • Hooks as CI checks — The PreToolUse and PostToolUse hooks become quality gates in the pipeline
  • Agents in CI — The agent files are packaged in the repository and run on every PR
  • Automatic code review — The docs-review-agent runs automatically on every pull request
  • Test automation — The testing-agent runs the full suite and reports in the PR

Direct connection: the orchestrator.py you created in capsule 04 becomes the script that GitHub Actions runs.

Guide #11: Security Deep Dive

The security guide goes deeper into aspects we touched on superficially here:

  • Boundary enforcement — From rules in system prompts to real technical enforcement
  • Secrets management — The PreToolUse hooks that block .env are extended with secrets scanning
  • Agent permissions — --allowedTools and --disallowedTools as a security model
  • Audit trails — The SubagentStop logs are extended with complete audit logs
  • CLAUDE.md security policies — Security policies as part of the team constitution

Direct connection: the pre-tool-validate.sh hook you created here becomes the foundation of security scanning in Guide #11.

Part 8: Complete Guide Summary

What you knew before this guide

  • You used Claude Code as an interactive tool
  • You had experimented with basic subagents
  • You knew hooks at an introductory level
  • CLAUDE.md was an instructions file

What you know now

  • Custom Subagents (M1): Create agents with their own identity — roles, tool restrictions, specialized system prompts, defined output formats. Each agent is a specialist with clear boundaries.

  • Agent Memory (M2): Configure memory scopes (session, project, global) so the agents share context and remember decisions between sessions. Memory turns stateless agents into agents with history.

  • Parallel Delegation (M3): Delegate tasks to multiple agents simultaneously, manage dependencies between them, and resolve merge conflicts. Parallelism multiplies speed without multiplying errors.

  • Agent Teams (M4): Organize agents into teams with a coordinating team lead, a task board with formal dependencies, and communication protocols. The team lead doesn't execute — it coordinates, forwards context, and resolves conflicts.

  • Plugins (M5): Package agent files, skills, and hooks into distributable npm packages. One npm install configures a complete team of agents. Semver versioning for change control.

  • Hooks + SDK (M6): Hooks as the nervous system (7 events: SessionStart, PreToolUse, PostToolUse, SubagentStart, SubagentStop, Stop, PermissionRequest) and the headless SDK as programmatic control (Python and TypeScript).

  • Remote Control + CLAUDE.md (M7): CLAUDE.md as the team constitution — shared standards that all the agents respect. Remote control to approve operations from your phone. Governance without micromanagement.

  • Multi-Agent System (M8): 5 agents working in coordination with a task board, parallel execution, automatic quality gates, monitoring via the SDK, and a continuous-improvement retrospective. From tool to system.

The mental leap

BEFORE:  Me → prompt → Claude → result → I review → next prompt

NOW:     I design the system → 5 agents execute → hooks validate →
         SDK monitors → reports are generated → I analyze results →
         optimize for the next execution

The change isn't quantitative (faster, more code). It's qualitative: you went from operating a tool to designing an automation system. The difference between a pilot who flies a plane and an engineer who designs the autonomous navigation system.

Part 9: Final Deliverables

Completeness checklist

Verify that you have all the module's deliverables:

MODULE 8 — DELIVERABLES
═══════════════════════

Agent Files:
✅ .claude/agents/team-lead.md
✅ .claude/agents/backend-agent.md
✅ .claude/agents/frontend-agent.md
✅ .claude/agents/testing-agent.md
✅ .claude/agents/docs-review-agent.md

Hooks:
✅ scripts/hooks/post-edit-lint.sh
✅ scripts/hooks/pre-tool-validate.sh
✅ scripts/hooks/subagent-stop-log.sh

Configuration:
✅ .claude/settings.json (hooks configured)
✅ CLAUDE.md (team constitution)

Plugin:
✅ multi-agent-plugin/package.json
✅ multi-agent-plugin/agents/ (5 agent files)
✅ multi-agent-plugin/skills/team-conventions.md

Monitoring:
✅ scripts/monitor/team-monitor.py
✅ scripts/monitor/orchestrator.py
✅ scripts/monitor/metrics.py
✅ scripts/run-team.sh

Documentation:
✅ docs/reports/ (execution reports)
✅ docs/retrospective.md (retrospective template filled)

Logs:
✅ logs/agents/agent-activity.log (generated by execution)

Skills checklist

SKILLS MASTERED
═════════════════════

Custom Subagents:
✅ Create agent files with YAML frontmatter
✅ Define roles, boundaries, and output formats
✅ Restrict tools per agent

Agent Teams:
✅ Configure the team lead as a coordinator (not an executor)
✅ Design a task board with dependencies
✅ Manage parallel execution

Hooks:
✅ PreToolUse for validation and blocking
✅ PostToolUse for auto-linting
✅ SubagentStop for logging

SDK:
✅ Run Claude Code from Python
✅ Parse JSON results
✅ Real-time monitoring

Governance:
✅ CLAUDE.md as the team constitution
✅ Plugins for distribution
✅ Remote control for approvals

System Design:
✅ Design a multi-agent architecture
✅ Analyze performance and bottlenecks
✅ Optimize for the next iteration

Part 10: What's Next?

Immediate next step

Choose ONE thing from your retrospective and apply it. Don't try to do all 10 optimizations at once. Choose the one with the most impact for the least effort:

  • If context forwarding was the problem → update the team lead
  • If boundaries were violated → add the enforcement hook
  • If the task board was inefficient → redesign with more parallelism
  • If the testing was insufficient → improve the testing-agent

Next guide: CI/CD Pipelines

When you're comfortable with the local multi-agent system, move on to Guide #10: Claude Code in CI/CD Pipelines. There you'll integrate this system into GitHub Actions so it runs automatically on every PR.

Next guide after: Security Deep Dive

After CI/CD, Guide #11: Security Deep Dive goes deeper into everything we touched on superficially here: the permissions model, secrets scanning, audit trails, and security policies in CLAUDE.md.

The improvement cycle

Execute → Monitor → Analyze → Optimize → Execute again
    ↑                                          │
    └──────────────────────────────────────────┘

This cycle doesn't end. Each execution gives you data. Each retrospective gives you insights. Each optimization improves the next execution. The multi-agent system isn't a finished product — it's a living system that you improve continuously.

Capsule Summary

  • The retrospective analyzes results per agent: what did each one produce? does it match what was expected?
  • The performance analysis identifies slow agents, idle time, and coordination overhead
  • The conflict analysis documents type mismatches, naming inconsistencies, boundary violations, and dependency violations
  • The 10 optimizations cover: context forwarding, parallel tasks, maxTurns, naming conventions, boundary enforcement, task granularity, pre-checks, review templates, error reporting, and cost tracking
  • The 4Ls template (Liked, Learned, Lacked, Longed For) structures the retrospective
  • The V2 checklist prioritizes improvements for the next execution
  • The guide connects with CI/CD (Guide #10) for pipeline automation and Security (Guide #11) for system hardening

Part 11: Anti-Patterns — What NOT to Do

The 7 most common anti-patterns

After multiple executions of the multi-agent system, these are the errors that repeat the most:

1. A team lead that executes code

The team lead has Read and Glob to understand the context, not to implement. If you give it Write or Edit, sooner or later it will decide that it's "faster to do it itself" and produce code that doesn't follow the conventions of the specialized agent.

2. Agents without explicit boundaries

"Work on the frontend" is not a boundary. "Work in src/components/, src/pages/, src/hooks/, src/styles/" is. Vagueness produces overlap, and overlap produces conflicts.

3. A task board without dependencies

A task board where all the tasks are "none" in dependencies is a to-do list, not a task board. Dependencies are what enable parallelism and prevent errors.

4. Implicit context forwarding

Assuming the frontend-agent will "see" the types the backend published isn't enough. The team lead must explicitly forward which files, which types, and which endpoints are available.

5. Testing before code exists

The testing-agent that starts before the implementation tasks finish produces tests that don't compile, fixtures that assume nonexistent code, and false errors that waste turns.

6. Hooks that are too strict

A PreToolUse hook that blocks every rm without context will block legitimate operations like deleting obsolete test files. Hooks must be specific: block rm -rf / but allow rm tests/test_old.py.

7. Not maintaining a running summary

Without a running summary, the team lead loses the context of the first tasks by the time it reaches the final report. The context window isn't infinite — the summary compensates for that limitation.

Complete Guide Summary

Advanced Claude Code Workflows — Guide #9 of 11

8 modules · 3 phases · 8-10 hours

ModuleCore LearningDeliverable
M1Create agents with their own identity3 custom subagent files
M2Memory scopes for shared contextConfigured memory hierarchy
M3Parallel delegation with mergeRefactor executed in parallel
M4Agent Teams with task boardFunctional team of 3 agents
M5Distributable pluginsPublished npm plugin
M6Hooks + headless SDKAutomated end-to-end pipeline
M7Remote control + CLAUDE.mdTeam governance
M8Complete multi-agent system5 agents + hooks + monitoring

The guide's arc:

Individual (M1-M3)     → Team (M4-M5)       → System (M6-M8)
"One agent does X"     → "Agents coordinate" → "The system self-operates"

The result: A multi-agent development system you can adapt to any project. The agents are templates — change the roles and the system works the same. The hooks are gates — change the rules and the quality holds. The monitoring is observability — change the metrics and you still have visibility.

You didn't build a project — you built a capability.

Additional Resources

  1. Create Custom Subagents (Anthropic Docs) — Base reference for the entire agent system
  2. Claude Code Hooks — Hooks as quality gates and the nervous system
  3. Claude Code CLI Reference — Headless SDK, flags, and execution modes
  4. Claude Code Settings — Hook and preference configuration
  5. Claude Code Best Practices — Automation best practices
  6. Multi-Agent Orchestration — Multi-agent orchestration patterns
  7. Prompt Engineering: System Prompts — System prompts for specialized agents
  8. Claude Code Overview — General context of Claude Code as a platform

Final Note

You finished the most advanced guide in the path. What you built isn't a demo — it's a functional system. The agent files, hooks, monitoring scripts, and the plugin are real artifacts you can use tomorrow in your project. Adapt the roles, adjust the boundaries, change the tech stack, but keep the architecture: coordination via task board, automatic quality gates, monitoring via the SDK, and governance via CLAUDE.md.

The multi-agent system doesn't replace your judgment. It amplifies it. You design, the agents execute, the hooks validate, and you analyze the results. The continuous-improvement cycle is what turns a good system into an excellent one.

Next guide: Guide #10 (Claude Code in CI/CD Pipelines) integrates everything you built here into GitHub Actions. The agent files get versioned in the repo, the hooks become CI checks, the SDK orchestrates executions on every PR, and the multi-agent system becomes part of your development pipeline. What runs in your terminal today, runs in the cloud tomorrow.

← Previous4. Monitoring — SDK for Observability, Remote Control for Approvals