Implement Spec - Implement Specifications in Parallel Using Sub-Agents

Skill Overview

Read a specification (spec) and its associated ticket task graph, dispatch multiple implementation sub-agents to code in their own independent Git worktrees in parallel, and finally consolidate everything into a PR that fully implements the spec.

Applicable Scenarios

1. An existing specification and decomposed tickets need end-to-end implementation. The spec and tickets are ready; what is missing is turning them into code. This skill handles creating branches, opening a draft PR, advancing tickets in dependency order, and continuing until the entire spec is implemented.
2. Large changes need to progress across modules in parallel. When a spec involves multiple modules that do not block one another, implementing them sequentially wastes time waiting. The skill continuously calculates the set of tickets currently ready to start (the frontier), allowing independent work to proceed simultaneously.
3. The entire spec needs to become a reviewable PR. All implementation sub-agents’ output is merged into the same PR branch by a dedicated merge sub-agent. Finally, the code is reviewed as a whole, and the deliverable is a complete, readable, reviewable PR rather than a collection of scattered branches.

Core Functions

1. Proceed according to the task graph, not a step-by-step checklist. The skill treats tickets as a task graph with blocking relationships. At any given time, there is a “frontier”—tickets whose prerequisites have all been satisfied and that can be started immediately. After reading the task graph, the skill takes available tickets from the current frontier and assigns them for parallel implementation.
2. Implementation sub-agents work concurrently in independent worktrees. Each implementation sub-agent has its own Git worktree and branch, so they do not interfere with one another and can safely work in parallel. They should be run in the background whenever possible to maximize concurrency.
3. A merge sub-agent consolidates the work, followed by a unified code review. Once each implementation sub-agent finishes, a dedicated merge sub-agent merges its work into the PR branch. A merge may unlock a new frontier, and the skill dispatches additional implementation sub-agents accordingly. After all tickets are complete, the PR branch undergoes a /code-review; all issues are assigned to a single implementation sub-agent for one-time resolution. Finally, the PR is marked ready for review, and all implementation sub-agents’ worktrees are cleaned up.

Frequently Asked Questions

Can it be used with only a spec and no associated tickets?

No. This skill assumes that the specification has already been decomposed into tickets with blocking relationships—it is responsible for “implementing in parallel according to the task graph,” not for breaking the spec down into tickets. If you only have a spec, first use a planning skill to decompose the requirements into tickets, then hand them over to this skill.

Why does each implementation sub-agent need its own Git worktree?

Because they modify the codebase concurrently. Sharing the same working directory would cause changes to overwrite one another and create branch-switching conflicts. Independent worktrees give each sub-agent a clean, isolated workspace. Their changes are first committed to their own branches and then consolidated into the PR branch by the merge sub-agent.

Can this skill be triggered automatically by the model?

No. Its definition includes disable-model-invocation: true, meaning it can only be invoked explicitly by the user; the model will not decide on its own to start it. This is intentional: the skill creates branches, launches multiple sub-agents, and consumes significant resources, so a person should decide when to begin.

Can multiple sub-agents modifying code in parallel cause conflicts?

Worktree isolation prevents workspace-level conflicts, but semantic conflicts may still occur—for example, when two tickets modify the same file. The skill reduces this likelihood through the task graph’s blocking relationships, ensuring that dependent tickets do not start simultaneously. Final merging and code review provide additional safeguards. If the ticket decomposition has substantial overlap, it is recommended to adjust the breakdown first.