/implement-with-subagents

name: implement-with-subagents
description: Use when implementing or reviewing the orchestration of supplied tickets or plan tasks through separate implementation subagents, including queue atomicity, task-scoped commit acceptance, and repair ownership.
compatibility: "Review mode has no external skill dependency. Implementation mode requires Matt Pocock's separately installed `implement` workflow; its current contract also invokes `tdd` and `code-review`."
disable-model-invocation: true

Implement with subagents

Keep orchestration and implementation ownership separate: the controller schedules, and one implementation subagent owns each independent work item through completion. Keep changes that cannot validate apart in one item, accept its task-scoped commit before advancing, and return failed acceptance evidence to that same owner rather than repairing it in the controller or reassigning it.

Check The Prerequisite

Review mode has no external skill dependency. Implementation mode requires the `implement` skill from [Matt Pocock's skill set](https://github.com/mattpocock/skills), which is not bundled with this repository. Install it with `npx skills add mattpocock/skills`, selecting `implement`, `tdd`, and `code-review` as required by the current upstream contract. Never install it implicitly.

Select the mode

• Use `review` only when the user asks to assess supplied orchestration without

running it.

• Use `implement` when the user asks to execute the supplied tickets or plan

tasks.

Review procedure

1. Inspect only the repository and supplied orchestration state that the user permits. Do not start a subagent, edit files, create a commit, or contact a remote service. 2. Assess queue atomicity, dependency order, implementation ownership, task-scoped acceptance, repair ownership, and controller mutation boundaries. Treat an already accepted item as complete rather than assigning it again. 3. Report the next orchestration action, or that no action is needed, with the evidence and any unresolved acceptance gap. Stop before the implementation procedure.

Implementation procedure

1. Read the repository instructions and inspect the current branch and worktree. Preserve unrelated changes. Stop before delegation when a task-scoped commit cannot be produced safely from the current state. 2. Resolve and read the installed `implement` skill. Treat it as a required dependency. If it is unavailable, stop before making changes. Report that it comes from `mattpocock/skills`, provide `npx skills add mattpocock/skills`, and state that the user must select `implement`, `tdd`, and `code-review`. Never install them implicitly or reproduce the procedure from memory. 3. Build a dependency-ordered queue. Keep an unsplit request and its checklist in one work item; group supplied items only when they cannot validate in separate behavior-preserving commits. 4. Process one item at a time. Record `HEAD` and the pre-existing worktree state before each item; accept the preceding item before starting the next. 5. Select the portable **Solver** role and map it to the runtime's implementation-capable subagent type. Record the portable role and actual runtime selection when the environment exposes it. Spawn one owner. Do not implement any part of the item in the controller. If an implementation slot is temporarily unavailable, wait for capacity. If subagents cannot be started, stop and report the blocker rather than falling back to controller implementation. 6. Give that owner a decision-complete packet containing:

• the exact ticket or plan task and its acceptance criteria;
• the relevant specification and repository instructions;
• exclusive ownership of that work item on the current branch;
• the pre-existing worktree state that must be preserved;
• an instruction to invoke the installed `implement` skill; and
• an instruction to return the commit, the evidence required by the installed

`implement` skill's current finish contract, and any unresolved blocker. 7. Wait for that owner before starting another. Do not split its implementation across agents. If the result is incomplete, dirty, uncommitted, or fails a required check, return the evidence to the same owner. Stop on a material blocker it cannot resolve within the supplied contract. 8. Independently accept the item before advancing; an owner's report is not acceptance evidence. Verify:

• verify `HEAD` advanced by at least one task-scoped commit;
• inspect the complete commit range and diff from the recorded `HEAD` to the

current `HEAD` for the work item's acceptance criteria and scope;

• inspect the returned command, complete result, tested revision, and relevant

input and environment identity;

• reuse a requested check only when its complete evidence shows success,

the relevant environment remains unchanged, and neither the user nor repository requires a fresh independent run. Also require either the tested revision to equal current `HEAD`, or current `HEAD` to be a descendant of the tested revision whose independently inspected diff leaves the check's relevant inputs unchanged;

• repeat each affected check when its evidence is missing, failed, tied to an

unexplained older revision, affected by a changed relevant input, or subject to an explicit freshness or independent-run requirement;

• confirm the returned evidence satisfies the installed `implement` skill's

current finish contract; and

• verify the task-owned diff is empty relative to the recorded pre-existing

state. 9. After every repair, repeat the independent commit and diff inspection, then reassess the evidence under step 8. Reuse only checks whose relevant inputs and environment remain unchanged across the inspected descendant diff; repeat affected checks. An unexplained older revision is