Turning Matt Pocock's /implement into a parallel orchestrator in Claude Code

I moved my Claude Code workflow from the superpowers plugin to Matt Pocock's skills. The chain /grill-with-docs → /to-spec → /to-tickets → /implement is great, but /implement is deliberately one ticket per session, with a /clear in between. Matt's own docs say batch dispatch and subagent fan-out are "requested repeatedly, and neither exists."

Meanwhile Claude Code already has everything an orchestrator needs: spawn a subagent, get its report, and send it a follow-up that resumes with its previous context intact. That is the orchestrator-subagent pattern from Anthropic's multi-agent coordination patterns post, and it maps onto Matt's tickets almost one to one.

So I kept the planning half of Matt's flow and replaced only the build half with a skill called /implement-orchestrated. Here is how it fits together.

The shape

	/implement (Matt)	implement-spec (Matt's unshipped draft)	/implement-orchestrated
Unit	one ticket per session	whole spec	whole spec
Parallelism	none	implementer subagents in worktrees	coder subagents in worktrees, up to N
Review	/code-review at the end	/code-review at the end	reviewer per ticket, then code-review + final-reviewer
Fix loop	same session	unspecified	SendMessage to the same coder

Four Claude Code features carry the whole thing:

• Agent tool with subagent_type: implement-orchestrated:coder (the namespaced form a plugin install gives you; hand-copied into ~/.claude/agents/ it is the bare coder) and isolation: worktree
• SendMessage to a finished subagent by name: it resumes from its transcript
• worktree.baseRef: which commit subagent worktrees branch from
• .worktreeinclude: copy gitignored files into each worktree

The loop

1. Read the spec and tickets. Build a state table (ticket, blockers, status, coder, branch, worktree) in a file outside the repo, because it has to survive context compaction.
2. Create the feature branch, record a test baseline, open a draft PR.
3. Dispatch the frontier (every ticket whose blockers are closed) to coder subagents, up to N at once, each in its own worktree.
4. When a coder reports, spawn a reviewer. On "Needs fixes", save the findings to a file and send the same coder the path. It already knows the ticket, the code, and what it did; the pointer is enough. Two failed rounds escalate to the human.
5. Merge with --no-ff, run the full suite, close the ticket, remove the worktree, recompute the frontier, go to 3.
6. At the end: Matt's code-review skill, a final-reviewer pass, push, mark the PR ready.

The brief each coder gets is three lines:

Ticket: <ticket pointer>. Spec: <spec pointer>. Notes: <notes>/notes.md (read it if it exists).

You are in your own git worktree on your own branch; every command and edit stays inside it. It holds tracked files plus any local config listed in `.worktreeinclude`, so run the project's install step (for example `npm ci`) before the first test. The glossary is `CONTEXT.md` in your worktree; if it is missing, read <main checkout>/CONTEXT.md and <main checkout>/docs/agents/. Build this ticket.

Everything else, the TDD discipline, the report format, lives in the agent definition, not in the message.

The coder agent

The old coder I had was five generic lines. Rewritten to fit Matt's tdd skill, it now carries the two ideas that skill runs on: pre-agreed seams (decide where tests go before writing any) and reporting by context pointer (branch, SHAs, test command) instead of pasting diffs.

---
name: coder
description: Use for coding tasks delegated to a subagent: implementing a ticket or spec slice, fixing a bug, refactoring, writing tests. Works test-first at pre-agreed seams and reports by context pointers. Runs on Opus 5 with max reasoning effort.
model: opus
effort: max
---

You are an implementer executing one scoped coding task from a brief. The plan was settled upstream: build what the brief says, and raise a design objection in your report rather than redesigning as you go.

## Before writing code

- Read the ticket or brief, then the code at the seams it names. When `CONTEXT.md` or `docs/adr/` exist, read the parts that touch this area: use the glossary's terms in names and tests, and flag any ADR your change would contradict.
- Seams are pre-agreed: the brief or ticket names them. When it names none, test at the public boundary where the acceptance criteria are observable, and name that boundary in your report.

## Building

- Work as one vertical slice, red → green: call the Skill tool with "tdd" and follow its loop, one failing test then the minimal code, seam by seam. When the interface shape itself is in question, call the Skill tool with "codebase-design".
- Typecheck often and run single test files as you go; run the full suite once at the end. Done means every acceptance criterion has a passing test at a seam, or a stated reason it cannot.
- Commit on your current branch with a message that references the ticket. Merging, pushing, and the issue tracker belong to whoever dispatched you, unless the brief says otherwise.

## Report

Your final message is the return value; the caller saw none of your tool calls. Report by context pointer: branch, worktree path, commit SHAs, the test command and its result, the seams you tested at, and anything the ticket left ambiguous. Under 200 words; the diff speaks for itself.

isolation: worktree is deliberately not in the frontmatter. The orchestrator passes it per call, so the same agent still works for a plain bug fix.

Two settings that make it work

Worktree base ref. By default a new subagent worktree branches from the remote default branch (origin/main). The orchestrator merges each finished ticket into the feature branch and then dispatches the tickets that depend on it, so with the default, ticket 03's worktree branches from origin/main and never sees ticket 01's merged code: the coder builds on stale code, or re-implements ticket 01 and conflicts at merge. With head, every worktree branches from the current tip of the feature branch:

{
  "worktree": {
    "baseRef": "head"
  }
}

Letting Claude edit ~/.claude/settings.json for you may get refused by the permission classifier (it was in my run), so run this yourself once, then start a fresh session:

python3 -c "import json;p='$HOME/.claude/settings.json';d=json.load(open(p));d.setdefault('worktree',{})['baseRef']='head';json.dump(d,open(p,'w'),ensure_ascii=False,indent=2)"

Gitignored files. A worktree holds tracked files only. My glossary (CONTEXT.md) and tracker config (docs/agents/) are gitignored, so a .worktreeinclude file (gitignore syntax) tells Claude Code to copy them into every worktree it creates:

CONTEXT.md
docs/agents/
docs/adr/
CLAUDE.local.md

List specific paths. Do not list .claude/ wholesale: .claude/worktrees/ holds your other worktrees and would be copied into every new one, recursively, gigabytes at a time. Name the subfolders you need instead (.claude/hooks/, .claude/skills/, .claude/settings.json). And the Agent tool's worktree isolation does not run your PostToolUse hooks, so .worktreeinclude is the only thing that copies untracked files into a coder's worktree.

Things that bit me

• User-invoked skills can't be called by the orchestrator. Skills with disable-model-invocation: true (Matt's /implement, /to-spec) throw when called through the Skill tool. That is why the TDD discipline moved into the coder's prompt.
• A plugin's agents array is not loaded. The manifest reference documents "agents": [...] in plugin.json, but on Claude Code 2.1.265 the version that declared it registered nothing (claude plugin details said Agents (0)), and the version that dropped the array and relied on the default agents/ directory registered all three (Agents (3)), namespaced.
• The Workflow tool can't continue an agent. Each agent() call there is fresh. The "same coder, previous context" property needs Agent + SendMessage inside a skill.
• Worktree cleanup. Claude Code removes a subagent worktree that finished without changes, but keeps one with unpushed commits. Coders commit, so the fix round lands in the same place.
• Don't run parallel /implement sessions in one checkout. Matt's docs have a field report of one session's git commit --amend landing on another session's commit. Worktrees are the insurance.

What happened when I ran it

After publishing I ran /implement-orchestrated screenshot-source 3 on the same spec (2026-09-08, on my Chrome extension ryoshumei/add-to-calendar; the result is PR #14).

• All 8 tickets closed, zero escalations. 01, 02 and 07 went out three-wide at 06:17; seven tickets were merged by 08:07. Active orchestration time was about 1h50 for tickets 01 to 07, plus about 50 minutes for the last ticket and the final gate.
• The same-coder fix loop works. Ticket 07's first review came back Needs fixes (a new Deno test broke the flagless deno test invocation). One SendMessage with the path to the findings file, and the coder committed the fix (8b2a729) on the same branch in the same worktree; round two was Approved. The cwd question from the first version of this post is answered: it stayed put, three times out of three.
• Two surprises. Tickets 04 and 05 touched the same files and conflicted at merge; instead of resolving in the main checkout, the orchestrator resumed 04's coder and had it merge the feature branch first. A flaky test traced back to the signed-in fixture leaving a second Supabase client alive; ticket 04's reviewer found the root cause, ticket 06 fixed it, and a maintenance ticket was logged.
• What hurt most was the Claude rate limit. coder and reviewer are pinned to Opus with max effort; the eighth coder died at spawn with a 429 session limit. The orchestrator reported instead of hanging, and once allowed to continue it built that docs-only ticket itself, a logged deviation from "the orchestrator writes no feature code".
• Numbers: 30 commits on the branch, +4,373 / −299 lines across 42 files. Playwright tests 27 → 89, Deno 86 → 89, final suite green. Subagent tokens about 3.24M in total (coders 1.61M, per-ticket reviewers 0.68M, final gate 0.96M).
• Honest footnote: running Claude Code's built-in /code-review max on the branch afterwards produced 23 more findings (3 flagged as security), not yet fixed. The orchestrator's final gate did not catch those.

Get it

The skill, the three agents, and install notes:

https://github.com/ryoshumei/implement-orchestrated

claude plugin marketplace add ryoshumei/implement-orchestrated
claude plugin install implement-orchestrated@ryoshumei

Requires Claude Code 2.1.263 or newer; the current plugin version is 0.1.2. Installed as a plugin the agents are namespaced (implement-orchestrated:coder, implement-orchestrated:reviewer, implement-orchestrated:final-reviewer); copied by hand into ~/.claude/agents/ they are the bare coder / reviewer / final-reviewer, and the orchestrator handles both. claude plugin details implement-orchestrated@ryoshumei should list Agents (3).

You also need Matt's plugin installed and /setup-matt-pocock-skills run once per repo; the orchestrator reads the tracker config that step writes.