Implement a Spec as a Task Graph

What it does

The skill expects a specification and associated tickets with explicit blocking relationships. Ready tickets form a frontier; completing a dependency unlocks more work. Each implementer uses a separate branch and worktree, begins from the integration branch and brings its branch up to date before handing back work. A merger integrates completed tickets. The workflow calls the collection’s TDD discipline for implementation and code-review for closure, using context pointers to avoid duplicating large documents across agents.

When to use it

• A specified feature has independent tickets plus clear dependency edges.
• Several agents need to work without modifying one shared checkout.
• A team wants one integration branch and one coherent feature review.

Step-by-step workflow

1. Read the approved spec and ticket graph, including blockers and completion criteria.
2. Create the integration branch and identify the ready frontier.
3. Assign each ready ticket to a fresh implementer in its own worktree using the agreed TDD workflow.
4. Integrate completed changes, update the frontier and resolve conflicts before scheduling newly ready work.
5. Review the entire integration branch, fix findings, resolve tracker work and clean up implementer worktrees.

Example request

Use implement-spec for the approved bulk-import specification and its dependency-linked tickets. Keep all work on one integration branch. Schema validation must finish before import execution; the results screen can proceed after its contract is settled. Use isolated implementer worktrees, synchronize before integration and run the project checks. Review the combined feature against the spec before marking work ready. Do not deploy, merge into the default branch or change production data.

Worked example

Consider validation, import execution and a results screen. If execution depends on the validation contract, running both against separate guesses creates integration debt. The task graph should unlock execution after that contract lands. A screen ticket can run concurrently only when its own prerequisites are resolved. The integration branch collects compatible changes and supplies a meaningful whole-feature review. Passing individual ticket checks is insufficient if the combined error reporting violates the original spec.

What you get

A reviewed integration branch implementing the complete ticket graph, with tracker closure or a ready draft PR as appropriate to the project.

How to evaluate the result

• Confirm every implementer starts from the integration branch rather than an unrelated base.
• Check that blocked tickets do not start against unsettled contracts.
• Run combined feature checks and spec review before resolving the overall work.

What you need

An approved spec, dependency-aware tickets, Git worktrees, fresh subagents, tracker access and runnable tests. The companion tdd and code-review skills are required by the source.

Setup and activation

The publisher documents plugin setup for Claude Code, Codex and Copilot, and manual Agent Skills setup for Gemini CLI and other clients. Choose one distribution method per client to avoid duplicate skills. The engineering collection expects project-specific tracker, triage-label and document-location settings from setup-matt-pocock-skills. Keep referenced companion skills and files available. This catalogue review does not install or run them; scan the exact source before any later installation. Client tools, permissions and subagent support still need separate validation.

Limits and considerations

This is an orchestration workflow with a substantial tool footprint. It does not make shared database migrations or external side effects safe to parallelize. Tracker mutation, branch integration and deployment permissions remain distinct. A host without worktrees or subagents cannot execute the full documented flow.

Related workflows

• Use to-spec and to-tickets to prepare the spec and dependency graph.
• Use diagnosing-bugs for an integration failure that needs a reproducible signal.

License and reuse

MIT at repository level (Copyright 2026 Matt Pocock). Preserve the copyright and permission notice when redistributing substantial source material; inspect any separately licensed dependencies or assets.

Further reading

• Publisher README: client setup and companion skills
• Reviewed SKILL.md (immutable commit)
• Reviewed MIT license