mattpocock/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.

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 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 the integration branch. If the issue tracker closes work through PRs, or the user asks for one, open a draft PR after the first merge in step 5 (a branch with no commits ahead of main can't open one), marked as closing the spec and tickets.
Use implementer subagents to implement each ticket, each in its own worktree on its own branch. Each implementer subagent:
- confirms its worktree is based on the integration branch before starting, and resets onto it if not;
- calls the Skill tool with tdd to build the ticket;
- merges the integration branch tip into its own branch before reporting done
Once an implementer subagent completes, merge its work to the integration 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, call the Skill tool with code-review on the integration branch. Fix all issues raised by the code review in a single implementer subagent.
If a draft PR exists, mark it ready for review. Otherwise, resolve each ticket the way the issue tracker closes work, and report the integration branch.
Clean up all implementer subagent worktrees.

Files2

2 files · 1.2 KB

Select a file to preview

Overall Score

72/100

Grade

B

Good

Grades are signals, not a certification. Always review a skill yourself before use.

Safety

76

Quality

68

Clarity

75

Completeness

65

Summary

A meta-skill for orchestrating multi-agent implementation workflows. It coordinates subagents (exploration, implementer, merger) to execute a spec and linked tickets as a task graph on an integration branch, with support for concurrent work, draft PRs, and code review integration. The skill assumes a pre-existing issue tracker and spec.

Detected Capabilities

subagent invocationgit operations (branch creation, merging, worktree management)file reading (spec and tickets)context pointer managementconcurrent process coordination

Trigger Keywords

Phrases that agents use to match this skill to user intent.

implement specspec to codeticket workflowintegrate branchesconcurrent implementationsubagent orchestration

Risk Signals

INFO

Subagent invocation without guardrails on subagent capabilities or scope

Steps 2, 4, 5, 7 — subagents are spawned to perform exploration, implementation, merging, and code review

INFO

Git worktree creation and cleanup without documented safeguards against orphaned state

Steps 4, 9 — worktrees created for each implementer subagent and cleaned up at the end

WARNING

External file writes to 'directory outside the repo' for context sharing

Step 2 — exploration subagent saves markdown notes outside repo

WARNING

No documented rollback strategy if merges conflict or subagent fails mid-workflow

Steps 4–6 — merging and frontier updates assume success without explicit recovery guidance

Use Cases

Implement large specs with multiple dependent tasks across a codebase using subagent orchestration
Manage concurrent ticket implementation with task graph dependencies and safe merging
Coordinate exploration, implementation, and code review phases across subagents with context pointers
Execute structured feature rollouts from spec to integration branch with PR-based workflow

Quality Notes

Strength: Clear distinction between exploration, implementation, and review phases with well-defined subagent roles
Strength: Graph-based ticket dependency model and frontier concept are well-explained and promote concurrency
Strength: Context pointer discipline (sparse inter-subagent communication via references rather than duplication) is a sophisticated practice
Weakness: No explicit error handling documented — what happens if a subagent fails, a merge conflicts, or a worktree becomes corrupted?
Weakness: External file path for exploration notes is vague ('directory outside the repo, accessible by all future subagents') — no concrete guidance on naming, permissions, or cleanup
Weakness: Step 5 mentions 'merger subagent' but does not define what success or failure looks like for that subagent
Weakness: Missing precondition checks — Steps assume issue tracker exists, spec is well-formed, and initial setup is complete. Fallback guidance is minimal ('tell the user to run /setup-matt-pocock-skills')
Weakness: No edge case coverage for incomplete tickets, spec changes mid-flight, or circular dependencies in the task graph
Weakness: Step 7 code review says 'fix all issues raised' but does not explain how a single subagent handles complex review feedback or when review is 'complete'

Model: claude-haiku-4-5-20251001Analyzed: Sep 30, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

implement-spec