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.
npx agentmods add skills/zaxbyhub/opencode-swarm/ci-failure-batchingnpx skills add ZaxbyHub/opencode-swarm --skill ci-failure-batchinggit clone --depth 1 https://github.com/ZaxbyHub/opencode-swarmWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/zaxbyhub/opencode-swarm/ci-failure-batching)<a href="https://agentmods.dev/skills/zaxbyhub/opencode-swarm/ci-failure-batching"><img src="https://agentmods.dev/badge/skills/zaxbyhub/opencode-swarm/ci-failure-batching.svg" alt="Measured on agentmods" height="20"></a>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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00042 | $0.00586 |
| Opus 5 | $0.00021 | $0.00293 |
| Sonnet 5 | $0.00008 | $0.00117 |
| Haiku 4.5 | $0.00004 | $0.00059 |
Grade A, and why
ci-failure-batching 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 6d 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.
How it starts
The opening of the file, as written. The whole thing — 48 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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
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.
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.
- 6d ago First seen · 48 lines · 42 tokens per session scan A 1857f36196ec
ci-failure-batching is a skill published in the GitHub repository ZaxbyHub/opencode-swarm (464 stars, last pushed today), licensed MIT. It adds 42 tokens to every session and 586 once invoked, about $0.0002 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.
Other skills, from other repositories
hns-workflow-ci-loop
Unified CI watch + auto-fix loop skill. Polls gh pr checks after /moai sync PR creation, classifies required vs auxiliary failures, attempts safe automated patches (max 3 iterations), and escalates semantic failures to the user. Use for CI loop workflow — NOT for general loop iteration patterns (see…
slowest-tests
Find the top-N slowest test files in CI from a recent BuildKite run, optionally posting the results to a Slack channel as a formatted table. Use when asked to find slow CI tests, "what's making CI slow", or to post a slow-test report to Slack.
memstack-deployment-ci-cd-pipeline
Use this skill when the user says 'CI/CD', 'GitHub Actions', 'pipeline', 'continuous integration', 'continuous deployment', 'ci-cd-pipeline', 'automate deploys', or needs to set up automated build, test, and deployment pipelines. Do NOT use for one-time manual deployments.
ux-create-manifest
Create the initial Product UX Bible for an existing web or full-screen web app by deeply auditing the repository, using sub-agents when available, and generating docs/ux manifests, schemas, budgets, surface maps, action taxonomy, and design-token policies from observed code.
verify-changes
How to test and verify work in the dev-3.0 repo — which vitest config covers what, how to write a test that fits the house style, mocking Electrobun RPC and i18n providers, what coverage is actually expected, and the browser QA hand-off. Use when writing or fixing tests, deciding what a change needs covered, hitting a…
enterprise-agent-ops
Operate long-lived agent workloads with observability, security boundaries, and lifecycle management.