Capsule Driver

Capsule driver (the super-orchestrator seat)

Drive a slice's phases to completion through a tier of subagents in the main worktree. You hold the human's attention; everything below you is disposable context.

Announce at start: "Using the capsule-driver skill to drive SL-NNN through capsule orchestrators."

Why this exists

A slice's implementation costs far more context than one agent should hold. The tiering exists so that no single context exceeds ~250k tokens, where both cost and output quality degrade:

you (interactive, human attached)
  └── capsule-orchestrator     charters 2-4 phases, verifies, commits
        ├── capsule-phase-planner   one phase → runtime sheet
        └── capsule-worker          one phase → source delta

Your own discipline is to spend as little context as possible. You are not a reviewer of diffs; you are a spawner of orchestrators and a reader of their hand-backs.

Preconditions — check these before spawning anything

1. Session permission posture. Subagents inherit your mode, and a parent on bypassPermissions / acceptEdits cannot be overridden by a child. In default mode every background subagent's permission prompt surfaces in your session naming the asker — it will not deadlock, but it will pepper you and defeat the point. Confirm the operator is running a posture they are happy to have inherited by the whole tree.
2. Spawn depth. The tree needs 2 layers below you. The default is 3, but it was 1 in some releases, and at the limit Agent is silently withheld — an orchestrator that cannot spawn will quietly do the work itself. Pin it: CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH: "2" in settings.
3. No competing writers. Everything runs in the main worktree with no confinement. Confirm no other agent is active in this tree before you start.
4. The slice is planned. Design locked, plan.toml authored, phases exist. This skill implements a plan; it does not make one.

The loop

1. Charter an orchestrator: a named slice and a contiguous run of phases, typically 2–4. Spawn capsule-orchestrator with that charter, the slice id, and any standing constraint the human has set.
2. Read its hand-back. Check the per-worker model choices carry real arguments — "the default" is not one. Check what it adapted in the plan.
3. Charter the next orchestrator for the next run of phases. Expect to spawn a fresh one every 2–4 phases rather than resuming a tired one.
4. Record friction as it is reported to you (doctrine observation record).
5. Halt when phase implementation is complete. Do not begin audit.

What you escalate to the human

Subagents cannot ask — AskUserQuestion is withheld from every subagent, so an orchestrator's only channel is its return value. You are the entire escalation path. Bring the human in for high-impact decisions and governance conflicts where correct intent cannot be determined; decide the rest yourself.

Boundaries

• Not /dispatch. No worktrees, no forks, no confinement, no import step. Workers edit the real tree and orchestrators commit directly. If you need isolation or parallel file-disjoint phases, you want /dispatch instead.
• Do not implement. If you are editing files, the tiering has failed and you are burning the context it exists to protect.
• Do not audit. /audit is a separate stage with its own skill; route there after this skill halts.

Related

/plan and /phase-plan produce what this consumes. /audit is what comes after. /dispatch is the confined-worktree alternative to this skill.