/fleet

name: fleet
license: MIT
description: >-
  Parallel campaign orchestrator. Runs multiple campaigns in coordinated waves
  within a single session. Spawns 2-3 agents per wave in isolated worktrees,
  collects discoveries, shares context between waves. Use when work decomposes
  into 3+ independent streams that can run simultaneously.
user-invocable: true
auto-trigger: false
trigger_keywords:
  - parallel
  - simultaneous
  - multiple agents
  - at the same time
last-updated: 2026-07-30

/fleet — Parallel Coordinator

Use for 3+ independent work streams that can run simultaneously in isolated worktrees. Do NOT use for single-file scope, linear work, or when a marshal or skill suffices.

Orientation

**Use when:** Running 2+ independent work streams in parallel — tasks with non-overlapping file scopes that can execute simultaneously.

**Don't use when:** Work must execute sequentially or accumulate findings across phases (use `/archon`), a single orchestrated session is enough (use `/marshal`), or the task is simple enough for a bare skill.

Commands

| Command | Behavior | |---|---| | `/fleet [direction]` | Decompose direction into parallel streams, execute in waves | | `/fleet [path-to-spec]` | Read a spec file, decompose into streams | | `/fleet continue` | Resume from the last fleet session file | | `/fleet` (no args) | Health diagnostic → work queue → execute | | `/fleet --quick [task1]; [task2]` | Lightweight parallel mode for solo devs — 2+ tasks, single wave, governed merge, minimal durable receipt | | `/fleet --speculative N [direction]` | Try N different approaches to the same task in parallel — see Speculative Mode below | | `/fleet --teams [direction]` | Pilot: native task spine when `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` is set, see Teams Mode (experimental) below |

Protocol

Step 1: WAKE UP

1. Read CLAUDE.md (project conventions) 2. Check `.planning/campaigns/` for active campaigns 3. Check `.planning/coordination/claims/` for external claims 4. Determine input mode: directed, spec-driven, continuing, or undirected 5. **Load prior session context**: if `.planning/momentum.json` exists, run `node .citadel/scripts/momentum-read.cjs` and use the active scopes and recurring decisions to inform work queue prioritization. Skip silently if the file is absent or output is empty.

> **Wave context restoration:** Use the Claude Code Compaction API to restore fleet session context. Do NOT read `.claude/compact-state.json` — deprecated in favour of server-side compaction (available on Opus 4.6+). Fleet session files (`.planning/fleet/session-{slug}.md`) remain the source of truth for inter-wave discovery relay; compaction handles agent memory, not campaign state. If the Compaction API is unavailable, read the fleet session file's Continuation State directly.

Step 1b: LOG SESSION START + START WATCHER

Run `node .citadel/scripts/telemetry-log.cjs --event campaign-start --agent fleet --session {session-slug}`, then `node .citadel/scripts/momentum-watch-start.cjs`. The watcher runs in the background and re-synthesizes `momentum.json` within 500ms of any new discovery write. Safe to call if already running — one watcher per project.

Step 2: WORK QUEUE

Produce a ranked list of campaigns with columns: Campaign name, Scope (directories touched), Dependencies, Wave, Agent type. Rules:

• Independent items go in Wave 1; items that depend on Wave 1 results go in Wave 2
• Maximum 3 agents per wave (conservative default)
• Scope must NOT overlap between agents in the same wave
• After writing or changing a session queue, run `node scripts/fleet-steward.js --session .planning/fleet/session-{slug}.md` and use its `READY TO RUN`, `BLOCKED`, `MERGE NEXT`, `MERGE BLOCKED`, and `SCOPE CONFLICTS` sections as the operational DAG.
• If the steward reports `READINESS BLOCKED`, do not spawn that task in a high-autonomy wave unless a human verified the worktree and you pass `--override-readiness` intentionally.

Step 3: WAVE EXECUTION

For each wave:

1. **Prepare context** for each agent:

• CLAUDE.md content and `.claude/agent-context/rules-summary.md`
• **Map slice** (if `.planning/map/index.json` exists): run `node scripts/map-index.js --slice "<agent's scope keywords>" --max-files 15` and inject the `=== MAP SLICE ===` block; skip silently if no index
• **Prior session context** (all waves): re-read momentum fresh at each wave boundary via `node .citadel/scripts/momentum-read.cjs` and inject as a `=== PRIOR SESSION CONTEXT ===` block — a fresh read picks up discoveries from parallel Fleet sessions in other terminals; skip silently if empty
• Campaign-specific direction and scope, plus discovery briefs from previous waves
• Sandbox provider status when an agent has a known worktree: `node scripts/sandbox-provider.js status --provider worktree --worktree {path}`
• Which `.planning/` paths the agent may write and the merge strategy for each (see Shared State Merge Strategies)

2. **Log wave start**: `node .citadel/scripts/telemetry-log.cjs --event wave-start --agent fleet --session {session-slug} --meta '{"wave":N,"agents":["name1","name2"]}'` 3. **Spawn agents** with `isolation: "worktree"`, the host's native permission policy, and prompt = full context + direction 4. **Collect results** from all agents in the wave 4.5. **Validate wave results** — spawn one Phase Validator per agent (subagent_type `citadel:phase-validator`, Haiku, read-only, effort: low), all in a single parallel batch — never sequentially. Validator prompt: campaign slug, wave, agent name, exit conditions (the agent's scope goal and any stated conditions), and the agent's full HANDOFF text. For each verdict:

• **`pass`**: record the validator observation. The task becomes merge-eligible only after its deterministic gates and required Exit Evidence are also current, subject-bound, `passed`, and complete.
• **`fail`**: check the retry counter for this agent (max 2 retries in fleet; s