matt-implement-spec
Before using this method, read the knowledge and team rules: project knowledge comes from team-knowledge (tw brief).
You have been provided a spec. This spec should have tickets associated with it, describing how to implement the spec.
Use the project tracker and labels already configured. If absent, retain a local task draft.
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. The frontier contains tickets whose dependencies and applicable plan/review conditions are satisfied.
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.
Use subagents and worktrees only when authorized and useful. Otherwise execute the same task graph in the current agent, keeping the per-ticket acceptance and final review. When the project forbids extra checkouts (for example shared workspace files above the repository), skip steps 4–6's per-ticket worktrees and implement the frontier serially in the current checkout. For an existing team task, follow the team delivery rules, retaining valid approvals and each task's assessment. Simple work may remain in one task; approved scope does not add repeated kickoff or file-type pauses. Record authorized delegation using the existing ledger when needed.
Steps
- Read the spec and tickets to understand the task graph and parent business acceptance. For team work, run
startbefore the first source edit or implementer dispatch; read the actual readiness result. Carry unresolved issue IDs into every handoff.