You have been provided a spec. This spec should have tickets associated with it, describing how to implement the spec.
The goal is a PR which implements the entire spec on a single branch.
The tickets are not a list of steps. They are a task graph with blocking relationships between them. This means there is always a frontier of tickets which are ready to be grabbed.
Communication to and from subagents should be sparse. Communicate primarily through context pointers: to the spec, tickets, research notes, and previous commits. Don't duplicate information already available via pointers.
Implementer subagents should be run in the background where possible for maximum concurrency.
Steps
-
Read the spec and tickets. Read enough to understand the task graph.
-
(optional) Use an exploration subagent to conduct any exploration required by the tickets - relevant codebase files or external documentation. Ensure the exploration subagent can save files - it should save its markdown notes in a directory outside the repo, accessible by all future subagents. This lets implementer subagents focus on implementation rather than exploration.
-
Create a branch, and a draft PR. The PR should be marked as 'closing' the spec issue and tickets.
-
Use implementer subagents to implement each ticket. Each implementer subagent should work in its own worktree, on its own branch.
-
Once an implementer subagent completes, merge its work to the PR branch with a merger subagent.
-
If this changes the frontier of available tickets, kick off more implementer subagents to work on the new tickets. This allows for maximum concurrency.
-
Once all tickets are complete, run /code-review on the PR branch. Fix all issues raised by the code review in a single implementer subagent.
-
Mark the PR as ready for review.
-
Clean up all implementer subagent worktrees.