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. </EXTREMELY-IMPORTANT>

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:

1. Parallelism — Independent tasks execute simultaneously across multiple implementers
2. 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. </EXTREMELY-IMPORTANT>

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:

1. Reviewer approves → lead receives DM notification
2. Lead updates progress.md Dashboard — mark task complete, note key outcome
3. Lead reads agent planning dirs — aggregate findings to top-level .planning/findings.md
4. 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:

1. Update .planning/progress.md with final status
2. Send shutdown requests to all teammates
3. 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

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