ci-failure-batching
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.
git clone --depth 1 https://github.com/ZaxbyHub/opencode-swarm /tmp/ci-failure-batching && cp -r /tmp/ci-failure-batching/.opencode/skills/ci-failure-batching ~/.claude/skills/ci-failure-batchingSKILL.md
# 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 1. **DO NOT immediately fix the first failure.** Check if other jobs are still running: ``` gh pr checks <PR> --repo <repo> ``` 2. **If jobs are still running:** Note the failure, WAIT for the run to complete 3. **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 4. **Fix ALL failures in one changeset:** Cluster by root cause, fix each cluster, verify locally 5. **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. 6. **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.
>
Run a rigorous, quote-grounded codebase review or security/QA/accessibility/performance/AI-slop/enhancement audit. Use for full-repo or large-subsystem review reports; not for normal implementation. Performs Phase 0 inventory, selected exhaustive tracks with non-diluting depth, coverage closure, reviewer/critic validation, and writes .swarm/review-v8 artifacts without modifying source files.
>
>
Codex adapter for opencode-swarm destructive-command guardrail changes. Use before modifying src/hooks/guardrails.ts, checkDestructiveCommand, dcNormalizeCommand, shell-wrapper parsing, .swarm destructive-command blocking, or guardrails unit/adversarial tests.
>
Codex adapter for migrating opencode-swarm tests away from Bun mock.module leakage toward _internals dependency-injection seams. Use when touching tests with mock.module, adding test seams, fixing Bun mock isolation failures, or updating source modules for injectable internals.
Codex adapter for addressing pull request review feedback in opencode-swarm. Use when the user asks to fix PR review comments, requested changes, reviewer findings, CI-review notes, or a pasted review summary with low false-positive tolerance.