---

name: agent-fleet-coordination description: Use when you are running more than a couple of subagents against one repo and the hard part has shifted from splitting the work to merging it back safely - who owns which file, how results get reconciled, and how you prove the merged commit actually builds. Goes deeper than agent-fleet-orchestration on roles, file ownership, and the collect-then-apply loop.

Agent Fleet Coordination

This is the coordination layer that sits on top of a fanned-out fleet. Basic decomposition and briefing is covered by agent-fleet-orchestration. Reach for this skill once you have several agents touching the same repo at once and the risk is no longer "did I split the work" but "will the merged result be coherent and green".

When to trigger

• Three or more agents are editing files in one working tree.
• Agents need to touch shared state (package manifest, lockfile, a shared config) and could collide.
• You are about to push a commit that was assembled from several agents' output and need to trust it in CI.
• The first wave finished and you are deciding whether to re-fan a second wave or stop.

The orchestration loop

decompose  ->  fan out  ->  collect distilled results  ->  reconcile  ->  apply serially  ->  verify the commit  ->  (re-fan or stop)

1. Decompose into single-writer scopes. No two agents own the same file. See reference/file-ownership.md.
2. Fan out with tight per-role briefs. Finders are read-only, verifiers re-check independently, the orchestrator merges. See reference/roles.md.
3. Collect the distilled result from each agent (a conclusion plus file:line, a diff, a pass/fail), never the raw material.
4. Reconcile conflicts before writing anything to the tree.
5. Apply serially - the orchestrator is the only writer of shared state and the only thing that commits.
6. Verify HEAD, not the working tree, with scripts/verify-commit-tree.sh before pushing.
7. Decide: re-fan a follow-up wave, or stop because more splitting costs more than it saves. See reference/harvest-loop.md.

Reference files (open these for depth)

• reference/roles.md - the orchestrator / finder / verifier patterns: each role's single objective, its tool budget, and the exact deliverable shape it returns.
• reference/file-ownership.md - single-writer scopes, serializing shared state, and why you verify the commit tree and not the working tree.
• reference/harvest-loop.md - the collect-then-apply merge loop, re-fanning a second wave, and knowing when to stop.

Non-negotiables

• One objective per agent. "Research and also implement" produces thin implementation every time.
• Read-only agents get no write tools. Enforce it in the brief and in the tool budget.
• The orchestrator is the only writer to shared state and the only thing that commits and pushes.
• Never trust the working tree as proof. Verify the committed HEAD in a temp worktree.