implement-spec
You have been provided a spec. This spec should have tickets associated with it, describing how to implement the spec.
The issue tracker should have been provided to you. If not, tell the user to run /setup-matt-pocock-skills.
The goal is the entire spec implemented on a single integration branch, with every ticket resolved the way the issue tracker closes work.
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.
A ticket gets its worktree when it joins the frontier, cut from the integration branch tip of that moment. A blocked ticket holds no worktree: a base cut before its blockers landed is already behind by the time it starts, and turns a merge that should be a fast-forward into a conflict resolution.
Start every subagent with subagent, never subagent_fork: a fork inherits this conversation's completed turns, which is the context a worker was meant to start without.
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 run in the background without being asked, so issue their spawns in one message and then stop working. Each completion notice starts a new turn for you, which keeps concurrency at the graph's maximum.
Steps
- Read the spec and tickets to understand the task graph.