iterative-fleet

# Iterative Fleet A skill for reviewer-gated iterative loops of parallel `claude -p`, `codex exec`, or `pi -p` workers. Workers run per-iteration, a reviewer reads their output and writes a verdict, and a generated orchestrator decides whether to continue or stop — without ever killing or restarting workers. Supports Claude, Codex, and Pi providers — set per-fleet or per-worker. See dag-fleet SKILL.md for full provider documentation (model aliases, reasoning_effort, limitations). ## When to use this skill Reach for iterative-fleet when: - The work needs **multiple rounds of refinement** (not one-shot) - A **reviewer/verifier** must approve output before the work is done - You want **operator-declared stop conditions** (max iterations, LGTM count, cost cap) - Workers are long-running or have high bootstrap costs (no auto-restart — see CRITICAL section) Use dag-fleet instead when: - Workers run once and are done (no iteration needed) - There is no reviewer quality gate Use worktree-fleet instead when: - Tasks are fully independent with no shared state ## CRITICAL: No auto-kill, no auto-restart The orchestrator generated by this skill **reads and decides only**. It NEVER kills or restarts workers. Workers run to natural completion per iteration. This design comes from a $20 death spiral in experiment 001 where auto-restart on "stuck" workers caused cache rebuilds that cost more than the actual work. The reviewer is the quality gate. The operator is the kill switch. ## fl...