ArcBlock Fleet Report — read the fleet's telemetry back
The fleet writes one JSON record per round to fleet.jsonl. This skill turns that into
numbers, then says which of them deserve attention.
The one rule
You never compute, estimate, or restate a number that the script did not print.
The script is the fact layer; you are the judgement layer. Every count, rate, percentile and duration comes from its output verbatim. A number you produce yourself is indistinguishable from a correct one to the reader — that is precisely why it is forbidden. If a number you want is not in the output, say it is not measured rather than deriving it.
Step 1 — run it
bun "${AGENTLOOP_ROOT:-$HOME/.claude/plugins/marketplaces/arcblock-agent-skills/plugins/agentloop}/scripts/fleet-report.ts" $ARGS
$ARGS from what was asked:
| Asked for | Args |
|---|---|
| default / "how's the fleet" | --days 7 |
| a specific window | --days N |
| everything | (none) |
| a dashboard / "看图" / visual | --days 7 --html /tmp/fleet-report.html then open /tmp/fleet-report.html |
| a non-default deployment | add --file <path>/fleet.jsonl |
Default to --days 7. An all-time window buries a regression that started yesterday under
weeks of healthy history.
If it exits non-zero, report the message as-is — usually the file does not exist (no fleet on
this machine, or a different logDir). Do not invent a substitute path beyond the default.
Step 2 — read the output for what matters
Report the headline numbers, then work down this list. Only raise an item if its condition is met; a healthy fleet should produce a short report.
| Look at | Raise it when | Why it matters |
|---|---|---|
| field coverage | coverage < executed | Check this FIRST. Old records lack newer fields. Every rate below is over the covered subset only — say so before quoting any of them, or you will report a young field as a fleet-wide finding. |
| residual processes | any round > 0 | A round left processes running. These accumulate and burn the machine unattended; they are invisible without this number. |
| failures | failed > 0 | Name the repo×skill and the outcome (checkout-failed ≠ setup-failed ≠ failed). |
| skipped-locked | more than an occasional one | A round collided with its own previous round still running. Means the effective cadence is longer than configured — the repo's rounds outlast its interval. |
| noop rate | high, or rising | Rounds that ran and deliberately did nothing. Healthy for a review-shaped skill (pr-sweep reviews; it does not open PRs), suspicious for a work-shaped one (issue-sweep). Judge per skill, never in aggregate. |
| P90 vs median | P90 ≫ median | A long tail. Combined with skipped-locked, that tail is what is eating the cadence. |
| produced summaries | always worth reading | The only place a round says what it did in its own words. Quote one or two verbatim rather than paraphrasing — the wording carries the reason. |
Step 3 — say what to do
At most three suggestions, each tied to a number that appeared in the output. Prefer a concrete knob:
- long tail + lock collisions → raise
cadenceMinutesfor that repo, or split the skill - residual processes → note that the reap is per-round; residue means something escaped it
- a repo failing repeatedly → point at its per-(repo,skill) log, which the driver names in its own output
If nothing meets a threshold, say the fleet looks healthy and stop. Padding a clean report with speculation trains the reader to skim it, and the next real signal gets skimmed too.
Not this skill's job
- Per-issue or per-PR outcomes — those live on GitHub, which is their source of truth. This reads the fleet's view of its own rounds: how long, how often, what escaped.
- Changing anything. Read-only. Report a knob worth turning; do not turn it.