launch-swarm

**4 hours of my time. 40 hours of engineering output. This is the .claude folder.**
This is the exact .claude configuration I use daily to run a 6-agent AI engineering swarm from Claude Code. It plans sprints, writes code, reviews PRs, generates documentation with annotated screenshots, auto-merges after dual-gate approval, and hands off to manual QA. Fully autonomous.
I'm the CEO of AgentWeb, a 4-person team building AI marketing agents. This is the production workflow behind a real startup shipping real code every week.
I'm a part-time engineer. I code about 4 hours a day. The rest is sales, marketing, ops. This system turns those 4 hours into 40 hours of engineering output. The reason it works is the same reason real engineering teams work: roles, reviews, and rules about who can touch what. AI without that structure is just faster chaos.
---
Table of Contents
- System Architecture
- The 6 Agents
- Key Concepts
- Installation
- What You Need (Infrastructure)
- Mix and Match
- Magic Keywords
- PR Templates
- Customization Guide
- FAQ
- Credits
---
System Architecture
The swarm follows a linear pipeline with two quality gates before anything merges:
The Dual-Gate Rule
Nothing merges until **two independent gates** pass:
| Gate | Agent | What it checks |
|------|-------|---------------|
| **Gate 1** | Senior Reviewer | Code correctness, architecture, security, reliability |
| **Gate 2** | Docs Agent | Screenshots captured, blog draft written (for features), UI not broken |
The PR Watchdog only auto-merges after **both** gates approve. This catches an entire class of problems that tests alone miss: undocumented features, UI regressions that "work" but look wrong, missing screenshots for stakeholder review.
---
The 6 Agents
1. Sprint Worker
> **Role:** The coder. Pulls tasks from your sprint board, writes failing tests first, implements the fix, and opens a PR. Trigger: sprint worker or go ham.
**Runs up to 3 concurrent instances.** You can parallelize across multiple tasks.
**What it does every 30 minutes:**
1. Queries your sprint board for To-do tasks in the current sprint
2. Skips tasks owned by others or marked as blocked
3. Classifies risk level (Low / Medium / High)
4. Writes failing tests (minimum 3 failing + 1 passing), then implements until all pass
5. Opens a PR targeting your dev branch using the Reviewer-First format
6. Moves the task to In Review and picks up the next one
**What it does NOT do:**
- Never takes screenshots (that's the Docs Agent's job)
- Never self-assigns work from the backlog — only works on tasks **you** curated into the current sprint
- Never auto-converts research tasks into code changes
**Risk classification drives rigor:**
| Risk | When | What's required |
|------|------|----------------|
| Low | UI tweaks, CSS, copy changes | Unit tests |
| Medium | New pages, frontend logic | Unit tests |
| High | External APIs, payments, DB mutations | Unit + integration tests + manual QA steps + rollback plan |
**Domain gating** — certain areas require human approval before merge:
- **Payments/billing:** Ships with robust test plan, team lead owns
- **Auth (login, tokens, sessions):** PR opens but holds for CTO review
- **Core AI/agent infrastructure:** PR opens but holds for CTO review
- **Everything else:** Ships automatically through the pipeline
**Special mode — "Investigate:" tasks:**
Tasks prefixed with Investigate: trigger research-only mode. The agent reads code, checks logs, and writes findings — but **never writes code or opens PRs**. This creates a deliberate pause point where you decide whether to proceed with a fix.
**Standalone use:** Great on its own if you just want an autonomous coding agent. Pair it with the PR Watchdog for the minimum viable pipeline.
---
2. Task Planner
> **Role:** The architect. Reads code deeply, generates implementation plans with multiple options, but never writes a single line of code.
**What it does every 15 minutes:**
1. Finds To-do tasks in the current sprint that don't have plans yet
2. Deep-reads the codebase: finds relevant files, checks architecture, maps dependencies
3. Generates 3-4 implementation options, each with files to change, pros, cons, and risk assessment
4. Posts the plan as a comment on the task with a recommended approach
5. Marks the task as Planned so the Sprint Worker knows to follow the plan
**What it does NOT do:**
- Never writes code, opens PRs, or modifies files
- Never plans tasks owned by other team members
- Never works on Epics (13+ story points) — flags them for breakdown instead