harness:fleet-command

A coordinator for several installed groups of coding tasks, called fleets. It checks their queues, orders dependent work, and asks for confirmation before running it.

In plain words
What is it for?
Use it to coordinate CI checks, idea work, intake, quality reviews, and final merging across available fleets.
Why use it?
It removes the need to manually decide which groups should run first when their work depends on one another or may conflict.

Command for Claude Code

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/intense-visions/harness-engineering/fleet-command
Clone the repo
git clone --depth 1 https://github.com/Intense-Visions/harness-engineering

Made for: Claude Code.

Per session 254 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,534 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00254 $0.01534
Opus 5 $0.00127 $0.00767
Sonnet 5 $0.00051 $0.00307
Haiku 4.5 $0.00025 $0.00153

Measured 2d ago against content hash 662f07f89e35, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

harness:fleet-command scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.claude-plugin/commands/fleet-command.md · 41 lines

How it starts

The opening of the file, as written. The whole thing — 41 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Phases:

  • select: Determine which fleet members are installed, probe each one's queue depth through its own gate-free report-only path rather than reimplementing its selection and never through a gated dry-run path that would fire that member's own CONFIRM during selection, record a member with no gate-free path as queue-depth-unknown and carry it to the confirm round instead of guessing, drop empty-queue fleets as unscheduled rather than running them, derive the wave assignment from the fixed dependency shape with the CI trust gate first and ideation in its own wave ahead of intake and the independent quality sweeps parallel alongside intake and the land stage terminal so that no wave contains a dependency edge, apply the fleet cap structurally so the trust gate and the terminal lander are never shed, build the contention map over the four collision classes and the derived merge-order plan it implies, detect the run-level forks worth surfacing including an untrustworthy CI signal read from the CI member's own queue probe, and degrade the DAG to the members actually present while recording every member that is missing
  • confirm: Present the wave DAG, the fleet selection with its probed queue depths and its unknown-depth fleets and its unscheduled empty-queue fleets and everything the cap shed with the structural reason that shed it, the global budget of slots and the per-fleet sub-cap of 2 and one pass per fleet and the fleet cap and the wall-clock, the contention map with its serialization and merge-order consequences, and the detected forks with recommended defaults — including the CI trust fork whose options are to run the CI member alone this session or proceed with every downstream verdict labelled degraded or trim the fleets that lean hardest on the CI signal — together in one surface for a single run-plan authorization in which the human approves or trims fleets or re-tunes the budget once and trimming re-derives the DAG; this phase does not run at all under report-only
  • dispatch: Schedule one worktree-isolated lane per scheduled fleet wave by wave, each lane running the real member skill rather than a reimplementation of it and each dispatched with an explicit --concurrency set to its allocation from the global pool because that flag is the only seam the global cap has and a lane launched without it silently reverts to the member's own single-fleet default, admitting a lane to its fan-out phase only as a global slot frees and never co-scheduling a serialized pair and shedding rather than deferring any lane whose deferral would reach the terminal lander's wave, presenting each wave's ready fleets' own CONFIRM gates together in one batched round verbatim and unmodified, parking a lane that hits an unforeseen run-level fork while the other lanes continue, and comparing elapsed time against the wall-clock deadline at each wave boundary before scheduling the next wave so budget exhaustion stops new scheduling without killing in-flight lanes
  • verify: Confirm each lane from its emitted artifacts rather than its self-report — the terminal artifact exists in the form that member's contract specifies, per-item verdicts are present with the references they were drawn from and those references are independently spot-checked, and nothing was merged outside a human-authorized land inside the land member's own gate which is checked directly against every branch and PR the lanes touched — while staying within allocation is reported honestly as a dispatch-time-enforced property recorded as an assumption rather than as a verified check because no artifact records a lane's peak concurrency, and all-OS CI is recorded as not-applicable at this tier with its reason and never dropped silently
  • report: Emit one consolidated dashboard carrying a per-lane row with its wave and verdict and emissions and slot usage and parked forks, the cross-fleet-deduped filing list in which one defect raised by several sweeps becomes one row citing every lane that raised it, the recommended merge order with its regeneration sequence as advice rather than an action, the run's budget accounting, everything the budget shed named with its reason, and an assumptions-made note; never merge and never authorize a land

Read the full file on GitHub · 41 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 41 lines · 254 tokens per session scan A 662f07f89e35

Subscribe to this mod's changes

harness:fleet-command is a command published in the GitHub repository Intense-Visions/harness-engineering (19 stars, last pushed 2d ago), licensed MIT. It adds 254 tokens to every session and 1,534 once invoked, about $0.0013 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.