| name | ci-failure-batching |
| audience | swarm-plugin |
| description | Batch collection and fix protocol for CI failures. Triggered when any CI check fails on a PR. Prevents serial diagnose-fix-push cycles by collecting all failures before fixing. |
CI Failure Batching
Trigger
When the PR monitor surfaces pr.ci.failed. The event is batched after the
check set is complete and includes all known failed checks in failedChecks.
Protocol
- DO NOT immediately fix the first failure. Check if other jobs are still running:
gh pr checks <PR> --repo <repo>
- If jobs are still running: Note the failure, WAIT for the run to complete
- Once the run completes, collect ALL failures:
- Identify every check with
fail status
- For each:
gh run view <run-id> --log-failed
- Build a complete failure ledger
- Fix ALL failures in one changeset: Cluster by root cause, fix each cluster, verify locally
- Publish through
commit-pr. This skill owns diagnosis and fix-planning
ONLY (issue #2131 criterion E): before any commit or push, compose the
commit-pr skill for the commit message, PR body/invariant-audit/test-plan
discipline, and the push protocol. The batching goal is ONE push cycle
(collect all → fix all → push once), not literally one commit — a single new
commit containing all batched fixes satisfies the goal. Guardrail facts (verified in the
tool-before push guardrail): bare git push --force
and -f are deny-pattern-blocked; --force-with-lease is EXEMPT because it
refuses to overwrite remote work gained since your last fetch — commit-pr
mandates it for fork/rebase flows. Even so, prefer a normal new fix commit
over amending an already-pushed commit.
- Only re-push if NEW failures surface that were not in the original batch.
Why this matters
Without batching, N failures produce N push cycles. With batching, N failures produce 1 push cycle.
Example from session #1685:
- Without batching: 6 pushes (format → stale-assertion-1 → stale-assertion-2 → integration → merge-group → clean)
- With batching: 2 pushes (collect all → fix all → push once → clean)
Pr-monitor expectation
The pr-monitor should fire one pr.ci.failed event for the completed failing
check set, not one event per check. Still verify with gh pr checks before
fixing, because GitHub can append late merge-group or matrix jobs.
