Ci Triage
Diagnose a failing GitHub Actions run, find the first real error in the logs, tell a...
Install
npx skills add ParadevAI/Paradev --skill ci-triage -g -a claude-code -y- Repository
- ParadevAI/Paradev15.8k
- Category
- Git and review
- Updated
- 3d ago
- License
- See repository
- Context cost
- Lightabout 816 tokens
- Runs scripts
- No, instructions only
What it does
Diagnose a failing GitHub Actions run, find the first real error in the logs, tell a flake apart from a genuine failure, and identify the commit that broke it. Use when checks are red on a PR, a workflow failed, the build is broken, CI is flaky, or the user asks why a run failed or whether a failure is real.
Diagnose a failing CI run
The goal is one sentence a human can act on: which job failed, on what, and whether it is this PR's fault. A screenshot of red checks is not a diagnosis.
1. Find the first failure, not the loudest one
List the run's jobs and take the earliest failing one. Later jobs usually fail because an earlier one did, and their logs are longer and more alarming, which is why people diagnose the wrong job.
Within that job, find the first error, not the last. Build tooling prints a summary at the end that names the last thing to fail; the first error is what actually broke.
Skip past the noise that always appears in failing logs: deprecation warnings, peer dependency notices, cache misses. None of them fail a build on their own.
2. Classify before investigating
Read the first error and put it in one of four buckets. They have different fixes and mixing them up wastes the most time.
| Bucket | Signal | What to do |
|---|---|---|
| Real failure | Assertion, type error, or compile error naming code this PR touched | Report the file and line |
| Environment | Network timeout, registry 5xx, disk full, runner image change | Re-run; if it persists, it is infrastructure |
| Flake | Timing, ordering, or concurrency; passes on re-run | See step 4, do not stop at "re-run passed" |
| Pre-existing | Fails identically on the base branch | Not this PR's problem; say so explicitly |
Check pre-existing early. Fetch the most recent run on the base branch and compare the failing job. A PR blamed for a failure it inherited burns an afternoon.
3. Attribute it to a change
For a real failure, connect the error to a diff. Get the PR's changed files and check whether the failing test or module is among them, or imports something that is.
