---
name: subagent-driven-delegation
description: Execute an implementation plan with the Superpowers subagent-driven-development loop while every task is implemented by a verified Claude Architect Producer — isolated worktree, frozen Candidate Artifact, independent verification, fresh-context review, human-only acceptance. Use when executing a multi-task plan through delegation rather than editing directly.
---

# Subagent-Driven Delegation

```claude-architect-protocol
PROTOCOL_VERSION: 2.0.0
```

Superpowers `subagent-driven-development` (SDD) dispatches a fresh implementer subagent per task, reviews each task, and reviews the whole branch at the end. This skill runs that same loop with one substitution: **the implementer is a Claude Architect delegation, not a generic subagent.** Each task becomes a versioned Delegation Spec executed by an untrusted Producer in an isolated worktree, frozen as a Candidate Artifact, and independently verified by the runtime before any reviewer sees it.

Always present this skill as `/claude-architect:subagent-driven-delegation`.

Use `/claude-architect:delegate` for a single delegation. Use this skill when a plan has multiple tasks and you want the SDD ledger, per-task review, and final whole-branch review on top of verified delegation.

## What the substitution buys

Upstream SDD's task reviewer reads a diff and the implementer's report; it trusts that the implementer ran the tests it claims. Here that trust is removed:

| SDD stage | Generic subagent | Verified delegation |
| --- | --- | --- |
| Implement | Subagent edits the branch | Producer edits an isolated worktree it cannot escape |
| Test evidence | Implementer's report | Runtime re-runs verification on frozen bytes |
| Task review | Reviews a diff | Reviews the exact anchored candidate, never the implementer's context |
| Complete | Controller marks done | Only a human accepts, then integration is hash-matched |

The Producer's self-report is never evidence. It is a correlation aid and a summary; every reviewable fact comes from runtime evidence.

## Where this diverges from upstream SDD

Follow upstream SDD except on these four points, where a trust invariant governs. Do not "restore" the upstream behavior.

1. **No implementer resume.** Upstream says fix rounds 1–3 resume the original implementer with its context intact. Claude Architect forbids it: every attempt starts with fresh context in a fresh worktree. Every fix round is therefore a **new attempt** carrying the findings in a revised spec. The report file, not conversational memory, is the continuity.
2. **The controller never marks a task complete.** Upstream lets the controller close a task after a clean review. Here a task closes only after `decideCandidate` records a human `accepted` and `integrateCandidate` reports `applied`.
3. **Implementer self-review is not a review.** Upstream's implementer self-reviews before handing off. A Producer may summarize, but the gate is runtime verification plus `reviewCandidate`. Never let a self-report shorten the review.
4. **The controller never fixes findings.** Upstream already says this to protect controller context; here it is also a trust rule. The architect authors specs and reviews bytes. It does not edit Producer output into shape.

## Mapping to the Superpowers skills

Each upstream skill keeps its meaning; delegation supplies the enforcement.

| Superpowers skill | How it is realized here |
| --- | --- |
| `subagent-driven-development` | The loop itself, with the four divergences above. |
| `dispatching-parallel-agents` | A repository is shared state. Lanes on **disjoint** repositories are genuinely independent and dispatch concurrently; lanes on the **same** repository serialize on the repository lock and must never be presented as parallel. |
| `test-driven-development` | `expectBaselineFailure` is the fail-before/pass-after proof, and the runtime enforces it: the command must run at clean HEAD and must fail. A Producer's claim to have written a failing test first is not evidence. |
| `systematic-debugging` | A failed verification is evidence to read, not a reason to re-dispatch. Start from `unresolvedIssues`, then the per-command `stdoutRef`/`stderrRef`, then the frozen patch. Re-running an unchanged spec is the delegation form of guessing. |
| `verification-before-completion` | Independent verification runs on frozen bytes before any reviewer sees them, and `reviewCandidate` gates the human decision. Neither is skippable because the Producer says the work is done. |
| `requesting-code-review` | `reviewCandidate` is the per-task review; the final whole-branch review covers the cumulative attempts. The reviewer never shares the implementer's context, so the independence upstream asks for is structural rather than conventional. |

Two upstream assumptions do not survive the trust boundary, and the table above is where they break: an implementer cannot be resumed (fresh context per attempt), and a controller cannot close a task (only a human accepts).

## Setup

1. **Isolated workspace.** Delegation already isolates each attempt, but the *branch* still needs a home. Use `superpowers:using-git-worktrees`, or confirm the current branch is not `main`/`master` without the user's explicit consent.
2. **Clean checkout.** Delegation and controlled integration require an exact clean checkout: commit or stash tracked changes first, including tracked planning files such as `tasks/todo.md`. Git-ignored planning files are fine. Never use skip-worktree or assume-unchanged as a workaround.
3. **Workspace and ledger.** When Superpowers is installed, run its `scripts/sdd-workspace PLAN_FILE` and use the directory it prints. Otherwise use `<repo-root>/.claude-architect/sdd/<plan-basename>/`. Create `progress.md` whose first line is `# SDD ledger — plan: <plan file path>`. A ledger naming a different plan belongs to that plan: leave it alone and start your own.
4. **Resume, don't redo.** A task with a `Task <N>: complete` line is done. Re-dispatching completed tasks is the most expensive recoverable failure in this loop, and delegation makes it costly in Producer time as well. Trust the ledger and `git log` over your own recollection.
5. **Plan conflict scan.** Read the plan once. Batch every contradiction — between tasks, against Global Constraints, or a mandate that the review rubric treats as a defect — into one question before Task 1. Add one delegation-specific check: any task whose success criteria are not objectively checkable cannot become a Delegation Spec. Sharpen those criteria with the user now, because a Producer cannot be verified against a vague goal.

## The task loop

Record `BASE` (`git rev-parse HEAD`) before each task.

### 1. Brief

Run Superpowers' `scripts/task-brief PLAN_FILE N` (or extract the task's full text to a uniquely named file yourself). The brief is the single source of requirements and holds every exact value verbatim. Never make a subagent or Producer read the whole plan.

### 2. Author the Delegation Spec

Translate the brief into a spec per `/claude-architect:delegate` — success criteria, `writeAllowlist`, and verification commands. Two rules matter more here than in single delegation:

- **Verification commands carry the task's acceptance.** Whatever the brief calls "done" must be an executable check, because the runtime — not the Producer — decides whether it passed.
- **Widen `writeAllowlist` to allowlist consumers** when the task changes an exported contract, or add a repository-wide verification command. A src-only gate plus focused tests compiles neither, and the breakage lands on you at integration.

Set `expectBaselineFailure: true` only on a command that cannot pass at clean HEAD *by design*. It is all-or-nothing per command: split a command that mixes existing and to-be-created paths, or you disable the baseline signal for the whole command. The gate enforces the declaration both ways — a command carrying the flag that cannot run, or that passes, fails the baseline.

Watch the brief for acceptance criteria phrased as an absence ("no bare `except`", "the legacy label is gone"). The obvious gate is a text search expecting no match, and that gate matches the phrase in comments and docstrings too — so a Producer that documents *why* it avoided the pattern fails a check its code satisfies. Anchor such patterns to syntax, or assert over parsed structure.

### 3. Dispatch

Dispatch through the host's `Agent` tool using the `delegation-lane` agent so the task renders as a native subagent row, or call `delegate`/`delegatePipeline` directly in the foreground for short attempts. Never dispatch two implementation lanes against the same repository as if they were parallel — the runtime serializes them on the repository lock.

Take only `runId` from the lane report. On a malformed report, locate the run directory matching `specSha256` rather than redispatching.

### 4. Review the task

The runtime has already frozen the candidate and independently verified it. Now call `reviewCandidate` and read the exact unredacted patch, changed-path manifest, and verification evidence against the brief.

This is SDD's task review, and both verdicts are still required: **spec compliance** and **task quality**. A green verification report answers only the first. Never skip the review because verification passed.

Resolve any "cannot verify from the candidate" item yourself — you hold the plan and cross-task context. A confirmed gap is a failed spec review and enters the fix loop.

### 5. The fix loop

Blocking findings — spec ❌, Critical, or Important — enter the loop. Minor findings go to the ledger as deferred and are handed to the final review; they never extend the loop. A finding that conflicts with the plan's text is the user's call: present the finding beside the plan text and ask which governs.

Five rounds maximum per task. Each round is one new attempt plus one scoped re-review:

- Call `decideCandidate` with `revision-requested`. Frozen bytes are never edited.
- Author a **revised spec** carrying the open findings verbatim and a verification command covering each one. Rounds 4–5 raise the Producer's model or reasoning tier, and say plainly in the spec that prior attempts failed and why.
- Re-review the new candidate against the findings list: each finding ADDRESSED or NOT ADDRESSED, plus new breakage in this candidate only.
- Append: `Task <N>: fix round <R>/5 (<X> addressed, <Y> open — <one-liners>; run <runId>)`.

**The breaker.** When round 5 still leaves findings open, stop dispatching and adjudicate each one. Park a contestable or non-load-bearing finding with a written ruling. A finding that is real *and* load-bearing — a later task builds on it, or it reveals a plan defect — is a STOP: append `Task <N>: BLOCKED — <reason>` and report to the user with the finding, the plan text it collides with, and the attempt history. Adjudicate only at the cap; adjudicating earlier is pre-judging. Every adjudication is a ledger entry — silent discards are forbidden.

### 6. Close the task

Present the review outcome and your recommendation. The user decides.

On `accepted`, call `integrateCandidate` with the exact candidate `manifestHash` as `expectedArtifactHash`, and report `applied`, `conflicted`, or `aborted` truthfully. Integration stages the reviewed tree; it does not commit. One accepted candidate per clean checkout — never batch-accept against the same checkout.

Then append `Task <N>: complete (run <runId>, manifest <hash7>, review clean)` — or `…, <K> parked` after a tripped breaker.

**Gate before the next task.** Integration leaves the checkout dirty, and delegation requires an exact clean checkout — so the loop cannot advance until the staged tree is resolved. Stop here and have the user commit (or discard) it, then confirm `git status` is clean before authoring Task N+1's spec. This is the one mandatory pause per task; it is not a progress check-in, and it exists because the next `delegate` call will otherwise fail its precondition. Record the commit in the ledger alongside the completion line so the ledger stays a usable recovery map.

## Final review

After the last task, review the **whole candidate branch and the cumulative attempts**, not just the final diff — a defect introduced in Task 2 and papered over in Task 6 is only visible across the range. Dispatch the final review on the most capable available model, point it at the ledger's deferred-minor and parked lines, and give it the branch range from the merge base.

If it returns findings, handle them as one fix wave — a single revised delegation carrying the complete findings list, not one delegation per finding — then exactly one scoped re-review. Residual findings are adjudicated as at the breaker.

When the final review is clean and integrated, delete this plan's workspace; git history is the record. Then use `superpowers:finishing-a-development-branch`.

## Rationalizations

| Excuse | Reality |
| --- | --- |
| "Verification passed, skip the review" | Verification proves the checks ran, not that the spec was met. Both verdicts are required. |
| "I'll just resume the Producer with the findings" | There is no resume. Fresh context per attempt is a trust invariant; author a revised spec. |
| "The candidate is obviously fine, I'll accept it" | Only a human accepts. You recommend. |
| "It's a one-line finding, I'll patch it myself" | Controller edits skip review and cross the trust boundary. Revise the spec. |
| "The Producer says it ran the tests" | A self-report is never evidence. Read the runtime's verification report. |
| "Both lanes are on the same repo but they'll run in parallel" | The repository lock serializes them. Size timeouts accordingly. |
| "Round 6 will converge" | Past the cap the failure is structural. Adjudicate and route. |
| "Integration staged it, I can start the next task" | A staged tree is a dirty checkout, and delegation requires a clean one. The next task's dispatch will fail until the user commits. |