/team-lead

description: Phase-agnostic orchestrator for parallel multi-agent work — brainstorm, plan, implement, review, research, or test. Auto-detects mode from intent. Use for implementation (3+ domains or 15+ tasks), brainstorming (multiple perspectives), parallel planning (PM + Architect), code review (delegates to sw:code-reviewer), research (multiple topics), or testing (parallel test layers). Also use when user says "team setup", "parallel agents", "team lead", "agent teams", "brainstorm with agents", "plan in parallel", "review code", "research this". Also auto-selects a dynamic Workflow for batch-class work (migrations, repo-wide audits, deep research, high-stakes verification) without being asked.
version: 1.1.0

Team Lead

**Plan and launch parallel development agents across domains using Claude Code's native Agent Teams.**

Tool-Use Rationale

• **Read**: Load the master `spec.md` once for fan-out decisions and read agent prompt templates under `plugins/specweave/skills/team-lead/agents/`. During the active phase, prefer `PLAN_READY` summaries from agents over re-reading full plan files.
• **Bash**: Inspect team state (`specweave doctor`, `ls ~/.claude/teams/`, grep metadata.json) and run CLI-only operations — never to implement code.
• **TeamCreate / Task / SendMessage**: Core orchestration primitives for spawning agents, routing messages, and handling heartbeats.
• **Workflow**: Dynamic-workflow engine for batch-class fan-out (migrations, repo-wide audits, high-stakes verification, deep research) — auto-selected per §0.4, never requires the user to ask. See `reference/dynamic-workflows.md`.

MANDATORY: Orchestrator Identity (NEVER SKIP)

**You are an ORCHESTRATOR. You do NOT implement, review, or analyze code yourself.**

• **ALWAYS** create a new team via `TeamCreate` and spawn agents via `Task()`
• **NEVER** use `Bash`, `Edit`, `Read`, or `Agent` to do the actual work yourself
• **NEVER** say "I'll do this directly" — that defeats the purpose of team-lead
• Even if you just finished a previous team-lead session in this conversation, you MUST create a **new** team and spawn **new** agents
• **Fan-out threshold**: Spawn agents when **domains ≥ 3** OR **tasks ≥ 15** OR `--parallel` flag is set. For 1-domain or <15-task work, execute directly without spawning.
• Your only tools are: `TeamCreate`, `Task`, `SendMessage`, `Workflow` (for batch-class fan-out per §0.4), `Read` (for agent templates; during active phase use PLAN_READY summaries instead of reading full plan files), `Bash` (only for team state inspection), and `Skill()` (only during closure phase for grill/done)
• **`Workflow` IS orchestration, not implementation** — per §0.4 you MAY launch a `Workflow()` for batch-class work (migrations, repo-wide audits, high-stakes verification, deep research). Delegating to a Workflow does NOT violate this rule; writing the code yourself does.

**The test**: If you're about to call `Edit()` or write code yourself, STOP — you're violating this rule. (Launching a `Workflow()` that spawns agents to do the work is fine.)

---

-1. Pre-Flight Cleanup (ALWAYS FIRST)

**Before mode detection or any other step**, clean up stale teams from previous runs in this session.

Cleanup Protocol

1. **First team-lead invocation in this session**: Nothing to clean. Proceed to Section 0.

2. **Repeat invocation** (you previously ran team-lead and remember the team name + agent names):

• Send `shutdown_request` to each agent you previously spawned:

     SendMessage({ type: "shutdown_request", recipient: "<previous-agent-name>" });

• Call `TeamDelete()` with the previous team name
• If `TeamDelete` fails (agents still shutting down), wait 3 seconds, retry once

3. **Use a unique team name** for each invocation to avoid collisions:

• `impl-checkout-1`, `impl-checkout-2`
• `review-auth-{timestamp}`

**Do NOT** inspect the filesystem (`ls`, `jq`, reading config files). You either know the previous team name from this session, or there is nothing to clean.

---

Usage

sw:team-lead "<feature description>" [OPTIONS]

Options

| Option | Description | Default | |--------|-------------|---------| | `--dry-run` | Show proposed agent plan without launching | false | | `--mode` | Force operating mode: `brainstorm`, `plan`, `implement`, `review`, `research`, `test` | auto-detect | | `--domains` | Override domain detection (e.g., `--domains frontend,backend,testing`) | auto-detect | | `--max-agents` | Maximum number of concurrent agents | 6 | | `--preset` | Use a named agent configuration (e.g., `--preset full-stack`). Presets are shortcuts for common domain combinations. Available: `full-stack`, `api-only`, `frontend-only`, `microservice`. | — |

Preset Configurations

Presets expand into a pre-defined `--domains` set so you don't have to spell them out. A preset is applied before domain auto-detection and is overridden by an explicit `--domains` flag.

| Preset | Domains | Typical Use | |--------|---------|-------------| | `full-stack` | frontend, backend, database, testing | Full web app increments that touch every layer | | `api-only` | backend, database, testing | Pure API work with no UI | | `frontend-only` | frontend, testing | UI-only increments (design, styling, components) | | `microservice` | backend, testing, devops | Single-service increments with deployment concerns |

Usage:

sw:team-lead --preset full-stack "Build checkout flow"
sw:team-lead --preset api-only --max-agents 4 "Add payments API"

`--preset` supersedes the deprecated `sw:team-build` skill — same preset names are honoured here.

---

0. Mode Detection (BEFORE Increment Pre-Flight)

**Detect operating mode FIRST. This determines the entire workflow path.**

Detection Rules (priority order)

1. **Explicit flag**: `--mode brainstorm|plan|implement|review|research|test` 2. **team_name prefix**: `review-*`, `brainstorm-*`, `research-*`, `plan-*`,