/delegate

name: delegate
description: Let Claude Architect route a versioned implementation spec through the trusted MCP runtime, independently review the Candidate Artifact, record a decision, and integrate only accepted bytes. Use for implementation delegation, Producer selection, or commitment-boundary review.

Delegate

PROTOCOL_VERSION: 3.0.0

The current session is the architect: it owns requirements, the Delegation Spec, Producer selection, review, and acceptance. Producers are untrusted — their output is only a candidate until the runtime freezes it, independently verifies it, and the architect reviews the exact anchored bytes.

Always present this skill as `/architect:delegate`. Never show a shorter command.

Superpowers across the trust boundary

When the upstream Superpowers plugin is available, keep its host-loop skills on the architect side: `brainstorming` before freezing the Delegation Spec, `writing-plans` to turn an agreed design into objectively checkable work or slices, `verification-before-completion` before recording a decision. Generic `executing-plans` and `subagent-driven-development` may coordinate architect-owned non-writing analysis only, never a writing task.

To execute any multi-task plan that writes files, use `/architect:subagent-driven-delegation`: the Superpowers subagent-driven-development loop — ledger, per-task brief, per-task review, final whole-branch review — with the delegation lifecycle below replacing the generic implementer subagent. No skill grants a Producer permission to plan instead of editing, dispatch nested agents, review itself, accept a candidate, or integrate bytes. Without the plugin, proceed without those skills rather than approximating them.

Edit-lane Producers receive a deliberately smaller, vendored procedure subset:

• `test-driven-development` for every behavior change or bug fix, before implementation code;
• `systematic-debugging` when a test, build, or behavior fails unexpectedly, before proposing a fix;
• `verification-before-completion` before claiming success.

The runtime supplies these by absolute path inside each isolated attempt. Never put architect-only skills in the Delegation Spec or tell a Producer to discover skills from the operator's home directory. Vendored from [obra/superpowers](https://github.com/obra/superpowers) 6.2.0, MIT.

Agent selection

The delegated CLIs are the architect's **implementation agents** — Claude Code's subagent idiom, except each agent launches an *untrusted Producer* through the trusted MCP runtime inside an isolated Git worktree. Present them as a roster: the human picks one `subagent_type`, exactly one agent runs per attempt, and no agent may review or accept its own work.

If the user invokes `/architect:delegate` without naming a CLI, implementer, or agent, use the host's structured question tool when available, ask this question, and wait for the answer. Include the producer and reasoning control in each option so the user knows what the lane will run:

> Which CLI should handle this delegation? Each choice shows its model and reasoning default. Use a custom answer to name a different supported reasoning level.

Offer exactly these choices:

• **Codex** - `codex-implementer`; GPT-6.1 Sol at `low` reasoning by default (supported overrides: `medium`, `high`, `xhigh`, `max`, `ultra`).
• **OpenCode** - `opencode-implementer`; configured provider/model unless overridden, with an optional model-specific `--variant` such as `high` when supported.
• **Pi** - `pi-implementer`; always uses the model configured in Pi (e.g. `xai/grok-4.7` as configured in Pi) — a spec naming a model override fails the lane rather than substituting one — with optional `--thinking off|minimal|low|medium|high|xhigh|max`.
• **Pythinker** - `pythinker-implementer`; configured provider/model unless overridden; the installed pythinker-code CLI exposes no reasoning override, so the Pythinker configured default always applies.
• **Antigravity CLI** - `agy-implementer`; configured model unless overridden, with optional `--effort low|medium|high`; darwin/arm64 only until a Linux/Windows write-confinement backend exists.
• **Claude Code** - `claude-implementer`; a second Claude session run headless as an untrusted Producer — the configured default model unless overridden with `--model opus|sonnet|fable|haiku` (opus = Opus 5.5, sonnet = Sonnet 5.5, fable = Fable 5.1), with optional `--effort low|medium|high|xhigh|max`; darwin/arm64 only, same Seatbelt backend. The attempt runs with settings, hooks, MCP servers, skills, and CLAUDE.md discovery disabled, so it sees only the Delegation Spec and cannot reach this plugin's own tools.

There is no implicit lane default. If the answer names a supported model or reasoning override, include it in the delegation spec; otherwise let the selected Producer use its configured default. The Pi lane accepts no model override: it always runs the model configured in Pi.

P0-A certifies the MCP implementation path only for Codex on macOS arm64 when its capability report names `codex-native-sandbox` and marks the edit Lane eligible.

Architect-side Claude subagents

The architect session — whatever model it runs, including Fable — may dispatch Claude subagents through the host's `Agent` tool (`model`: `opus`, `sonnet`, or `fable`) for **non-writing** roles, in parallel with a running lane:

• **Scout** (`sonnet`, or `Explore`): read-only reconnaissance before a spec is frozen — call sites, nearby patterns, which files an allowlist must cover.
• **Spec drafter** (`sonnet`): turn an agreed design into candidate `successCriteria` and verification commands for the architect to review; the architect still owns and freezes the spec.
• **Candidate reviewer** (`candidate-reviewer`, `opus`): an independent review of the frozen bytes through `reviewCandidate`, with no Producer context. Use it for the per-task review and for the whole-branch final review, the