Team-Driven Development

Execute plan by creating an Agent Team with persistent implementer teammates and a dedicated reviewer. Teammates work in parallel on independent tasks, with the reviewer providing continuous quality gates.

Core principle: Persistent teammates + parallel execution + dedicated reviewer = high throughput, context resilience, quality assurance

Announce at start: "I'm using the team-driven skill to execute this plan with an Agent Team."

NON-NEGOTIABLE: Reviewer Must Review Every Task

A task is NOT complete until the reviewer DMs the lead with APPROVED.

You MUST NOT:

Skip the reviewer for ANY reason ("task was simple", "just a config change")
Mark a task complete without reviewer approval
Proceed to the next parallelism group while any task has open review issues

The Task Status Dashboard in .planning/progress.md has Spec Review and Quality Review columns. A task row MUST show PASS in BOTH columns before you can set its status to complete.

When to Use

digraph when_to_use {
    "Have implementation plan?" [shape=diamond];
    "Tasks heavy OR parallelizable?" [shape=diamond];
    "Stay in this session?" [shape=diamond];
    "team-driven" [shape=box style=filled fillcolor=lightgreen];
    "subagent-driven" [shape=box];
    "executing-plans" [shape=box];

    "Have implementation plan?" -> "Tasks heavy OR parallelizable?" [label="yes"];
    "Have implementation plan?" -> "brainstorm first" [label="no"];
    "Tasks heavy OR parallelizable?" -> "Stay in this session?" [label="yes"];
    "Tasks heavy OR parallelizable?" -> "subagent-driven (lighter tasks, serial)" [label="no - light & serial"];
    "Stay in this session?" -> "team-driven" [label="yes"];
    "Stay in this session?" -> "executing-plans" [label="no - separate session"];
}

Two independent advantages over subagent-driven:

Parallelism — Independent tasks execute simultaneously across multiple implementers
Context resilience — Each teammate has its own full context window. Subagents share the parent's context limit and can crash on heavy tasks. Teammates don't have this problem.

Even without parallelism, team-driven is preferred for heavy tasks where a single subagent might hit context limits.

Team Structure

Team Lead (you, current session)
├── implementer-1 (teammate)  ──→ Task A ─┐
├── implementer-2 (teammate)  ──→ Task B ──┤── parallel
├── implementer-N (teammate)  ──→ Task C ─┘
└── reviewer (teammate)       ──→ reviews completed tasks

Team lead: Reads plan, creates tasks, assigns work, aggregates findings, updates progress.md
Implementers: Persistent teammates, each works on assigned tasks, DMs reviewer when done
Reviewer: Dedicated teammate for spec compliance + code quality review. DMs implementer for fixes, DMs lead when approved.

The Process

digraph process {
    rankdir=TB;

    "Read plan, identify parallelism groups" [shape=box];
    "TeamCreate + spawn implementers + reviewer" [shape=box];
    "Create tasks via TaskCreate with dependencies" [shape=box];
    "Assign Group N tasks to available implementers" [shape=box];

    subgraph cluster_per_task {
        label="Per Task (parallel within group)";
        "Implementer works on task" [shape=box];
        "Implementer DMs reviewer" [shape=box];
        "Reviewer reviews (spec + quality)" [shape=box];
        "Issues found?" [shape=diamond];
        "Reviewer DMs implementer to fix" [shape=box];
        "Reviewer DMs lead: approved" [shape=box];
    }

    "Lead: aggregate findings, update progress.md" [shape=box style=filled fillcolor=lightyellow];
    "More groups?" [shape=diamond];
    "Shutdown team, use finishing-branch" [shape=box style=filled fillcolor=lightgreen];

    "Read plan, identify parallelism groups" -> "TeamCreate + spawn implementers + reviewer";
    "TeamCreate + spawn implementers + reviewer" -> "Create tasks via TaskCreate with dependencies";
    "Create tasks via TaskCreate with dependencies" -> "Assign Group N tasks to available implementers";
    "Assign Group N tasks to available implementers" -> "Implementer works on task";
    "Implementer works on task" -> "Implementer DMs reviewer";
    "Implementer DMs reviewer" -> "Reviewer reviews (spec + quality)";
    "Reviewer reviews (spec + quality)" -> "Issues found?";
    "Issues found?" -> "Reviewer DMs implementer to fix" [label="yes"];
    "Reviewer DMs implementer to fix" -> "Reviewer reviews (spec + quality)" [label="re-review"];
    "Issues found?" -> "Reviewer DMs lead: approved" [label="no"];
    "Reviewer DMs lead: approved" -> "Lead: aggregate findings, update progress.md";
    "Lead: aggregate findings, update progress.md" -> "More groups?";
    "More groups?" -> "Assign Group N tasks to available implementers" [label="yes - next group"];
    "More groups?" -> "Shutdown team, use finishing-branch" [label="no"];
}

Step-by-Step

Step 1: Read Plan and Identify Parallelism

Read the plan file. Look for the ### Parallelism Groups section:

### Parallelism Groups
- **Group A** (parallel): Task 1, Task 2, Task 3
- **Group B** (after Group A): Task 4, Task 5
- **Group C** (after Group B): Task 6

If no parallelism groups are defined, treat each task as its own group (serial execution — still benefits from context resilience).

Determine MAX_PARALLEL = largest group size. This is the number of implementer teammates to spawn.

Step 2: Create Team and Spawn Teammates

TeamCreate: team_name="plan-execution"

# Spawn implementers (one per max parallel slot)
Task(team_name="plan-execution", name="implementer-1", subagent_type="general-purpose")
Task(team_name="plan-execution", name="implementer-2", subagent_type="general-purpose")
...

# Spawn reviewer
Task(team_name="plan-execution", name="reviewer", subagent_type="general-purpose")

Implementer teammate prompt: Use ./implementer-teammate-prompt.md template.

Reviewer teammate prompt: Use ./reviewer-teammate-prompt.md template.

The implementers spawned in this step are the ONLY implementers for the entire plan execution. You MUST NOT create additional implementers later, regardless of the reason.

If all implementers are busy → wait for one to finish, then assign the next task
If a new parallelism group has more tasks than implementers → run in waves (assign to implementers as they become free)
NEVER create an implementer named after a task (e.g., implementer-task6, implementer-task-N) — implementers are named implementer-1, implementer-2, etc. and are reused across all tasks

Creating new implementers mid-execution wastes resources, fragments context, and violates the persistent-teammate design.

Step 3: Create Tasks and Set Dependencies

Create all tasks via TaskCreate. Set addBlockedBy for tasks in later groups:

TaskCreate: "Task 1: ..." (Group A)
TaskCreate: "Task 2: ..." (Group A)
TaskCreate: "Task 3: ..." (Group A)
TaskCreate: "Task 4: ..." (Group B) → addBlockedBy: [1, 2, 3]
TaskCreate: "Task 5: ..." (Group B) → addBlockedBy: [1, 2, 3]
TaskCreate: "Task 6: ..." (Group C) → addBlockedBy: [4, 5]

Step 4: Assign Tasks

For the current group, assign tasks to implementers:

TaskUpdate: taskId="1", owner="implementer-1"
TaskUpdate: taskId="2", owner="implementer-2"
TaskUpdate: taskId="3", owner="implementer-3"

SendMessage: type="message", recipient="implementer-1", content="Please work on Task 1: [full task text from plan]"
SendMessage: type="message", recipient="implementer-2", content="Please work on Task 2: [full task text from plan]"
...

IMPORTANT: Include the full task text in the message. Don't make teammates read the plan file.

Step 5: Monitor and Aggregate

As teammates complete tasks:

Reviewer approves → lead receives DM notification
Lead updates progress.md Dashboard — mark task complete, note key outcome
Lead reads agent planning dirs — aggregate findings to top-level .planning/findings.md
Lead assigns next tasks to the same teammate that just finished if unblocked tasks exist — reuse the existing implementer pool, NEVER spawn new ones

Step 6: Shutdown

After all tasks complete:

Update .planning/progress.md with final status
Send shutdown requests to all teammates
REQUIRED SUB-SKILL: Use superpower-planning:finishing-branch

Per-Agent Planning Directories

Each persistent teammate maintains a single planning directory across all tasks:

mkdir -p .planning/agents/implementer-1/
mkdir -p .planning/agents/implementer-2/
mkdir -p .planning/agents/reviewer/

Implementers update the same findings.md and progress.md as they work on successive tasks. This keeps context continuous rather than fragmented across per-task folders.

Note: Subagent-driven follows the same convention — one directory per role (e.g., implementer/), reused across tasks. Do NOT create per-task directories like implementer-task-N/.

Prompt Templates

./implementer-teammate-prompt.md — Initial prompt for spawning implementer teammates
./reviewer-teammate-prompt.md — Initial prompt for spawning the reviewer teammate

Example Workflow

You: I'm using Team-Driven Development to execute this plan.

[Read plan: docs/plans/feature-plan.md]
[Identify groups: Group A (Tasks 1,2,3), Group B (Tasks 4,5), Group C (Task 6)]
[MAX_PARALLEL = 3]

[TeamCreate: "plan-execution"]
[Spawn: implementer-1, implementer-2, implementer-3, reviewer]
[Create all 6 tasks via TaskCreate with group dependencies]

=== Group A (parallel) ===

[Assign Task 1 → implementer-1, Task 2 → implementer-2, Task 3 → implementer-3]
[Send full task text to each implementer]

[implementer-1 working on Task 1...]
[implementer-2 working on Task 2...]
[implementer-3 working on Task 3...]

implementer-2 → reviewer: "Task 2 done. [report]"
reviewer → implementer-2: "Missing error handling for edge case X"
implementer-2: fixes issue
implementer-2 → reviewer: "Fixed. [updated report]"
reviewer → lead: "Task 2 approved"

implementer-1 → reviewer: "Task 1 done. [report]"
reviewer → lead: "Task 1 approved"

implementer-3 → reviewer: "Task 3 done. [report]"
reviewer → lead: "Task 3 approved"

[Lead: aggregate findings, update progress.md, unblock Group B]

=== Group B (parallel, after A) ===

[Assign Task 4 → implementer-1, Task 5 → implementer-2]
[implementer-3 is idle — can be shut down or held for Group C]

... same pattern ...

=== Group C ===

[Assign Task 6 → implementer-1]
... reviewer approves ...

[All tasks complete]
[Shutdown team]
[Use finishing-branch skill]

vs Subagent-Driven

Dimension	Subagent-Driven	Team-Driven
Parallelism	Serial only	Parallel within groups
Context lifetime	One-shot (dies after task)	Persistent (survives across tasks)
Context limit	Shares parent's limit	Own full context window
Review	New reviewer subagent per task	Persistent reviewer teammate
Communication	Through lead only	Peer DM (implementer ↔ reviewer)
Cost	Lower (serial execution)	Higher (parallel agents)
Best for	Light serial tasks	Heavy tasks, parallelizable work

Red Flags

Never:

Skip the reviewer for any task — this is the #1 rule. NO EXCEPTIONS. Every task MUST be reviewed (spec + quality) before it can be marked complete.
Create new implementers after initial setup — the implementer pool is fixed at Step 2. If all are busy, WAIT. Never spawn implementer-task6, implementer-taskN, or any ad-hoc implementer.
Assign two implementers to tasks that edit the same files
Let implementers communicate directly with each other (use lead as coordinator for cross-task concerns)
Proceed to next group before current group is fully reviewed and approved
Forget to aggregate findings from agent planning dirs

If teammate goes idle:

Idle is normal — it means they're waiting for input
Send them a message to wake them up with new work
Don't treat idle as an error

If teammate hits a blocker:

Teammate should DM lead describing the blocker
Lead resolves (provide info, reassign, or escalate to user)
Don't let blocked teammates spin

Integration

Required workflow skills:

superpower-planning:git-worktrees — RECOMMENDED: Set up isolated workspace unless already on a feature branch
superpower-planning:writing-plans — Creates the plan with parallelism groups
superpower-planning:finishing-branch — Complete development after all tasks

Complementary skills:

superpower-planning:verification — Final verification before declaring done