# Ci Triage

Diagnose a failing GitHub Actions run, find the first real error in the logs, tell a...

- Repository: https://github.com/ParadevAI/Paradev (15823 stars)
- Category: Git and review
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add ParadevAI/Paradev --skill ci-triage -g -a claude-code -y`
Codex: `npx skills add ParadevAI/Paradev --skill ci-triage -g -a codex -y`
Cursor: `npx skills add ParadevAI/Paradev --skill ci-triage -g -a cursor -y`
Gemini CLI: `npx skills add ParadevAI/Paradev --skill ci-triage -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add ParadevAI/Paradev`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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.

The rest: https://github.com/ParadevAI/Paradev/blob/HEAD/plugins/github/skills/ci-triage/SKILL.md