implement-plan

name	implement-plan
description	Orchestrates implementation of a multi-task plan by spawning plan-implementer subagents in parallel. Use when the user provides a plan file or plan text and asks to implement it, execute it, or says "implement plan", "run plan", "execute plan".

Implement Plan

You are the orchestrator. Your job is to execute the attached plan by delegating tasks to plan-implementer subagents. Preserve your context window for coordination — never implement tasks yourself.

Workflow

1. Analyze the Plan

Read the plan the user attached. Identify:

• All discrete tasks/steps
• Dependencies between tasks (which must run sequentially vs. can run in parallel)
• Any ambiguous items that need clarification before starting

If anything is unclear, ask the user before proceeding.

2. Group Tasks for Parallelization

Partition tasks into parallel batches based on dependencies:

Batch 1 (parallel): [tasks with no dependencies]
Batch 2 (parallel): [tasks that depend on batch 1]
Batch 3 (parallel): [tasks that depend on batch 2]
...

Rules:

• Max 4 concurrent subagents, to bound machine load and coordination overhead
• Tasks touching the same file(s) go in the same subagent or sequential batches — never parallel
• Small related tasks can be grouped into one subagent to reduce overhead
• Large independent tasks get their own subagent

3. Execute Batches

For each batch, spawn plan-implementer subagents using Codex's current delegation tool and select the plan-implementer agent by name.

Each subagent prompt must include:

• Exact tasks to implement (copy from the plan, don't paraphrase loosely)
• File paths and context needed to work independently
• Constraints or edge cases from the plan

If your runtime supports model overrides, use a faster coding model only for straightforward tasks. Omit the override for complex or cross-cutting tasks.

Wait for all subagents in a batch to complete before starting the next batch.

4. Handle Failures

When a subagent reports PARTIAL or FAILED:

• Read its report to understand what failed and why
• Decide: retry with more context, reassign to a different batch, or implement the fix yourself if trivial
• Don't retry blindly — adjust the prompt or approach

5. Verify

After all batches complete:

1. Run yarn build to confirm everything compiles
2. Run yarn lint and yarn type-check
3. If the plan touched React components/hooks, run the repo-standard verification commands and add yarn test when runtime behavior or tests changed
4. For UI changes, verify in the browser with playwright-cli across chrome, firefox, and webkit, plus a mobile viewport flow in each engine when relevant

6. Report

Summarize to the user:

## Plan Execution Summary

### Completed
- Task 1 — files modified
- Task 2 — files modified

### Failed (if any)
- Task N — reason, what was tried

### Verification
- Build: PASS/FAIL
- Lint: PASS/FAIL
- Type-check: PASS/FAIL

Key Principles

• You orchestrate, subagents implement. Don't code changes yourself unless it's a trivial one-liner fix for a subagent failure.
• Context is precious. Every build log and file read you do in the main thread is context you can't get back. Delegate liberally.
• Parallelize aggressively. The faster batches finish, the faster the plan is done. Only serialize when dependencies demand it.
• Verify at the end, not in between. Subagents run their own build checks. You do a final holistic verification.