Ci Triage
- 1 installs
- Updated July 23, 2026
- aguil/dotfiles
ci-triage is a Claude Code skill that triages a failing GitHub Actions check on a PR by finding the error, reproducing it locally and fixing it in one commit.
About
ci-triage is a Claude Code skill that structures how to triage a failing GitHub Actions check on a pull request. It finds the run with gh, skips setup noise to grep the first real error, reproduces it locally, fixes it in one isolated commit, then pushes and polls until the check turns green. It also covers flaky tests, infra outages and anti-patterns. A developer uses it whenever CI is red on a PR.
- Triages a failing GitHub Actions check on a PR into a green result
- Locates the run, extracts the first real error, reproduces locally, then fixes
- Isolates the fix in one focused commit and polls until the check flips green
Ci Triage by the numbers
- 1 all-time installs (skills.sh)
- Ranked #1,173 of 1,435 DevOps & CI/CD skills by installs in the Skillselion catalog
- Data as of Jul 24, 2026 (Skillselion catalog sync)
ci-triage capabilities & compatibility
- Capabilities
- ci triage · debugging · testing
- Works with
- github
- Use cases
- ci cd · debugging · testing
What ci-triage says it does
Structured approach to triaging a failing GitHub Actions check on a PR: find the run, extract the real error from logs, reproduce locally, fix in an isolated commit, push, and poll.
Goal: turn a red check green with the smallest, most reviewable commit possible.
npx skills add https://github.com/aguil/dotfiles --skill ci-triageAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| Last updated | July 23, 2026 |
| Repository | aguil/dotfiles ↗ |
What it does
Triage a failing GitHub Actions check on a PR: find the error, reproduce locally, fix in one commit and confirm green.
When should I use this skill?
a GitHub Actions check is red on a PR in the current task
What you get
A red CI check turned green with the smallest, most reviewable single commit.
- green CI check
- isolated fix commit
By the numbers
- 6-step triage loop
- 1 focused commit per failure
Files
CI triage loop
Goal: turn a red check green with the smallest, most reviewable commit possible. Don't fan out fixes across multiple commits — one failure, one focused commit.
1. Locate the run
GitHub Actions:
gh pr checks <pr> -R <org>/<repo> gh run list -R <org>/<repo> --branch <type>/<project>/<task> --limit 5 gh run view <run-id> -R <org>/<repo> --log-failed
If the project ships additional test-runner integrations (e.g. a dedicated test-results system reached via an MCP server or CLI), use those for richer log access. Any such work-specific integration is documented in ~/.agents/AGENTS.work.md and its companion skills.
2. Find the real error
Logs from CI wrap real errors in noise (setup, cache restore, etc.). Skip past:
- Setup / checkout / cache steps — they almost never fail usefully; if they do,
it's infra, not your code.
- "0 tests ran" lines — symptom, not cause; keep scrolling.
Grep for, in order:
FAIL|FAILED|ERROR|Exception|panic:
then narrow to the first occurrence
First error is usually the real one; subsequent failures cascade from it.
3. Reproduce locally
Never fix a CI-only error blind. Get it to happen on your machine first.
- Dart:
dart test path/to/failing_test.dart --reporter expanded - Flutter:
flutter test path/to/failing_test.dart - Java:
mvn -pl <module> test -Dtest=<TestClass>#<method> - Go:
go test ./pkg/... -run '^TestThing$' -v - Node:
npm test -- --testPathPattern=…
If it only repros in CI, the delta is the environment: network access, generated code freshness, or OS differences.
4. Fix in an isolated commit
One logical change, clear message:
Fix flaky ordering in FilterService tests
If the project's PR policy requires a tracker ID suffix on titles, see cross-repo-change/BRANCHING.md for the format.
If the fix changes production code _and_ regenerated clients, those are two commits (see dart-cross-repo on generated code hygiene).
5. Push and poll
from the project directory, for every repo in task.json:
just push <type> <task-id>
or for a single repo:
just push <type> <task-id> <repo-basename>
Watch:
gh pr checks <pr> -R <org>/<repo> --watch
Until the check flips green or produces a new, different failure.
6. When it's not your bug
- Flaky test: rerun once (
gh run rerun <run-id>). If it flakes again, file
a ticket and, if policy allows, mark the test as a known flake. Don't paper over with retries in production code.
- Infra outage: check the org status dashboard / #ci channel before burning
time.
- Dependency not yet released: you climbed the override ladder too early.
See cross-repo-change/DEPENDENCY-OVERRIDES.md.
Anti-patterns
- Force-pushing "fix ci" commits that don't actually change anything.
- Amending the same commit after each failed attempt so history is a lie about
the debugging process. Leave the trail; squash at merge time if the project's policy does that.
- Disabling a test as "the fix". Only acceptable with a linked bug ticket and a
comment explaining the plan.
Related skills
Azure DeploySafely execute production deployments of already-prepared applications to Microsoft Azure.485k1.3kAzure ValidateRun deep pre-deployment checks on Azure configuration, infrastructure definitions, RBAC roles, and managed identities before pushing to production.485k1.3k
Github Actions DocsGet precise, docs-grounded answers about GitHub Actions workflows, syntax, security, and migration instead of relying on stale knowledge.275k72
Setup Pre CommitAutomatically run Prettier, type checking, and tests on every commit via Husky and lint-staged.170k199k
Deploy To VercelSafely turn any local project into a live Vercel preview with one instruction.99.3k29.7kVercel Cli With TokensDeploy projects to Vercel from agents and scripts using token authentication instead of interactive browser login.74.6k29.7kFAQ
How does ci-triage find the real error?
It skips setup, checkout and cache steps and greps logs for FAIL, ERROR, Exception or panic, taking the first occurrence as the real cause.
What if it is not your bug?
For a flaky test it reruns once then files a ticket; for infra it checks the status dashboard; for an unreleased dependency it backs off the override ladder.