Subagent Driven Development

Subagent-Driven Development

> Adapted skill — discipline originating in Superpowers v5.1.0 (MIT, Jesse Vincent), rewritten in mattpocock-skills style. /mp-implement's Phase 3 execution engine when the Workflow tool is unavailable; may dispatch /mp-implement-issue as an implementer for a slice.

You are the controller. You never implement — every task goes to a fresh subagent with isolated context, keeping your own context free for coordination.

Setup

Read the plan once. Extract every task's full text, and note the scene-setting each needs: where it fits, what it depends on, the modules and callers it touches. Track all tasks in your todo list.

Dispatch

One implementer subagent per task, briefed from implementer-prompt.md. The brief is self-contained — the subagent never reads the plan file and cannot see your session:

• the task's full text, pasted in;
• the scene-setting you noted at setup — for unfamiliar areas, a map of the relevant modules and callers.

Note the base commit before the implementer starts, so reviewers get a clean diff range.

Run one implementer at a time. Answer its questions — before it starts or mid-work — before letting it proceed.

Per-task chain (order fixed)

1. Implement — builds, tests, commits, self-reviews. Self-review precedes review; it never replaces it.
2. Spec-compliance review loop — fresh reviewer from spec-reviewer-prompt.md; every finding quotes the spec line it violates.
3. Code-quality review loop — fresh reviewer from code-quality-reviewer-prompt.md over the base→head diff, entered only after spec passes.

Spec before quality: spec fixes rewrite the code a quality review would judge. A finding goes back to the SAME implementer — its context holds the code — and the fix is always re-reviewed. A task completes only when both reviews pass.

Implementer statuses

• DONE → proceed to spec review.
• DONEWITHCONCERNS → read the concerns first; correctness or scope concerns get addressed before review, observations get noted and ride along.
• NEEDS_CONTEXT → supply what's missing and re-dispatch.
• BLOCKED → diagnose: missing context → repair the brief; reasoning beyond the implementer → sharper brief or stronger model; task too large → split it; plan wrong → escalate to the human.

A BLOCKED or NEEDS_CONTEXT means something must change — re-dispatching the identical brief is not a response.

Continuous execution

Run the plan to completion without checking in with the user between tasks. Stop only for an unresolvable BLOCKED, genuine ambiguity, or completion.

Close-out

1. Dispatch one final reviewer over the whole diff, merge-base to HEAD, using the code-reviewer template.
2. Open PRs and move each issue to the tracker's awaiting-review status, per docs/agents/issue-tracker.md.
3. Work happens on a branch or worktree — the main branch only with explicit user consent. The parent spec issue stays untouched: never modified, never closed.

Model selection

Omit the model parameter by default so subagents inherit the session model. Override only with confidence — a clearly mechanical task for a cheaper model, a judgment-heavy one for a stronger. Never hardcode dated model IDs.

MP integration

The plan is the canonical spec decomposed by /to-tickets; each task is one AFK slice/issue. Required companions:

• using-git-worktrees — isolated workspace per slice.
• verification-before-completion — evidence gate before any slice counts as done.
• requesting-code-review — dispatch discipline and the reviewer brief for the review subagents.
• receiving-code-review — how fixes treat reviewer feedback: verify first, push back with technical reasoning when it's wrong.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: skywalkercyt
• Source: skywalkercyt/mp-implement
• License: MIT

Install and usage instructions live in the source repository linked above.