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 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/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<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="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Tool Misuse · line 30 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
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.00588 |
| Opus 5.5 | $0.00017 | $0.00235 |
| Sonnet 5.5 | $0.00008 | $0.00118 |
| 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 8d 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 — 49 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.
- 8d ago Changed · +1 lines c178b67e4c9f
- 1mo 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 (510 stars, last pushed today), licensed MIT. It adds 42 tokens to every session and 588 once invoked, about $0.0002 per session on Opus 5.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
ci-flaky-patrol
Classify a bounded batch of stale PR CI failures and choose the safest response.
github-actions
Use when authoring or fixing GitHub Actions CI/CD — workflows under .github/workflows, triggers, job matrix, caching, token permissions, OIDC cloud deploys, environment gates, reusable workflows. NOT the Dockerfile or image build strategy (that is docker), NOT the branching model (that is git-workflow), NOT release…
neon
Use when you have picked Neon (serverless Postgres) and need to connect correctly from a serverless or edge runtime, wire database branching into dev, preview and CI, or stop being burned by scale-to-zero cold starts and pooler limits — including choosing HTTP versus WebSocket connections and pooled versus direct…
deployment
Use when taking an app from source to live: choosing the deploy target from requirements (Hetzner+Coolify vs Vercel vs a third), then wiring container → CI → registry → host with build secrets, healthchecks and rollback. NOT one platform's mechanics (that is coolify, vercel, railway, render), NOT the Dockerfile alone…
task-project-health
Keep this project current and keep each check passing. Raise each dependency, repair each vulnerability, keep the lock file in sync, remove each unused package, check the runtime and the toolchain, and raise each action of the CI. Use when the user asks to upgrade the dependencies, to raise one package to a new…
hooksmith
Use when designing or reviewing safe Grok Build hooks for linting, tests, formatting, notifications, command guards, lifecycle automation, or project hook trust decisions.