execute-fleet

execute-fleet

Atlas Fleet is the premium parallel sibling of execute-task. It keeps the same proof discipline, but the orchestrator owns the scoreboard while workers only build inside isolated worktrees.

Hard Gates

Before the first wave, all gates must pass. If any gate fails, report the gap and stop; do not fall back to solo execution from inside this skill.

1. mcp__plugin_prd_go__detect_capabilities() reports tier: "premium" and atlas-launcher MCP registration/aliveness.
2. mcp__atlas-launcher__inbox_read is callable for this session.
3. .taskmaster/tasks/tasks.json exists.
4. .taskmaster/reports/task-complexity-report.json exists.
5. git status --short is empty. Fleet starts only from a committed base.
6. The integration branch policy is clear: use fleet-integration; main is never auto-touched.

SOLE-WRITER RULE: only this orchestrator writes .taskmaster/tasks/tasks.json and .atlas-ai/state/pipeline.json. Workers must never edit those files. The orchestrator may update task state only through TaskMaster or the plugin pipeline MCP, and only after verification.

Wave Loop

Repeat until no runnable tasks remain:

1. Call mcp__plugin_prd_go__compute_fleet_waves(concurrency=<N>, tag=<tag>). Use the returned frontier as the only dispatch source. If it reports a deadlock, render status, mark the blocked set, and stop dispatching those tasks.
2. For each chunk in the current wave, spawn exactly one worker: mcp__atlas-launcher__session_spawn(isolation="worktree", report_to=<this session>, model=<routing[task_id] model part>, prompt=<worker prompt>). Model is NEVER left default: compute_fleet_waves returns a routing map (task id -> backend:model) from the capability ladder — Fable for the hardest/longest-running (frontier tier), down the cost-efficiency curve to haiku for trivial tasks. Pass the model part explicitly; non-claude backends require experimental_backends=true and the launcher backend param. The prompt must include the full task JSON inline; never tell workers to read shared tasks.json.
3. Inspect the spawn result. If prompt_injected is false, re-kick once with mcp__atlas-launcher__session_send using the same worker prompt, then confirm injection/readiness. If it is still false, treat that worker as failed and apply the retry policy below.
4. Render the fleet status view after the wave starts and after each wave transition.
5. Poll mcp__atlas-launcher__inbox_read for terminal worker messages. The only accepted terminal status vocabulary is DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, or BLOCKED; any other terminal word is a protocol failure and counts as a worker failure.
6. On a completion message, verify the branch, never the narration:
   • The worker branch contains .atlas-ai/cdd/task-<id>.json.
   • No .atlas-ai/evidence/ file in that branch contains a non-zero Exit status N line.
   • The branch changed only its own worktree scope and did not edit .taskmaster/tasks/tasks.json or .atlas-ai/state/pipeline.json.
7. Never mark a task done without the CDD card. Missing card means the worker did not satisfy the contract, regardless of any DONE message.
8. Merge verified worker branches into fleet-integration sequentially, one at a time. After each merge, run the checker/build gate expected for the project before merging the next branch.
9. Mark the task done only after the merge gate passes: python3 script.py set-status --id <id> --status done.
10. Recompute waves after every accepted merge. Do not keep dispatching from a stale frontier.