/subagent-driven-delegation

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, runtime-gated acceptance. Use when executing a multi-task plan through delegation rather than editing directly.

Subagent-Driven Delegation

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 | The configured runtime authority records acceptance, 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 directly.** Upstream lets the controller close a task after a clean review. Here a task closes only after `decideCandidate` records `accepted` under the configured authority 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 Candidate 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 self-certify completion (acceptance is a durable runtime decision with recorded provenance).

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. This is the architect-owned integration workspace only: pass it as `checkoutPath`, but never dispatch a generic implementer to edit it. The runtime gives every implementation or repair attempt fresh context in its own isolated worktree. A repository delivery gate may later create another managed worktree; never reuse or expose one layer's worktree as another layer's workspace. 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-ign