CI Failure Batching
SkillDev toolsBatch 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.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the CI Failure Batching skill
What this skill tells your AI
The instructions your AI receives, as published by zaxbyhub/opencode-swarm in .opencode/skills/ci-failure-batching/SKILL.md and read by ahel’s review.
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
failstatus - For each:
gh run view <run-id> --log-failed - Build a complete failure ledger
- Identify every check with
- 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 thecommit-prskill 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): baregit push --forceand-fare deny-pattern-blocked;--force-with-leaseis 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.
Signals
- GitHub stars
- 469
- Forks
- 51
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
ci-failure-batching- Source
- github.com/zaxbyhub/opencode-swarm