Skip to content
Back to skills

Ci Failure Triage

ASecurity

Triage a CI / PR check failure by READING the failure body before forming any hypothesis. Triggered whenever a required check is red, a PR is BLOCKED, a merge won't land, or you're about to call a failure "transient", "flaky", "stale", or "orphaned". Prevents dismissing a real failure (e.g. real CodeQL security alerts) as noise.

  • 27 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 3, 2026
ai-agentsbashgitapisecurity

Works with

  • api

Security analysis

A100/100

Scanned September 3, 2026

npx -y skills add IgorGanapolsky/ThumbGate --skill ci-failure-triage --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ci Failure Triage?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Ci Failure Triage
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/igorganapolsky-ci-failure-triage/badge)](https://www.skillsdirectory.com/skills/igorganapolsky-ci-failure-triage)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: ci-failure-triage
description: >
  Triage a CI / PR check failure by READING the failure body before forming any
  hypothesis. Triggered whenever a required check is red, a PR is BLOCKED, a merge
  won't land, or you're about to call a failure "transient", "flaky", "stale", or
  "orphaned". Prevents dismissing a real failure (e.g. real CodeQL security alerts)
  as noise.
---

# CI Failure Triage — Read Before You Conclude

## The failure this prevents

Calling a red check "transient / flaky / orphaned / stale" WITHOUT reading its
body. This session: a CodeQL check failed; it was dismissed as a "transient 4s
orphaned check-run" — twice — when it was reporting **3 real security
vulnerabilities** (2 critical command-injection + 1 high XSS). The conclusion came
before the evidence. (2026 failure-triage practice = taxonomy → read → cluster →
gate, a *repeatable detection system*, not vibes:
https://latitude.so/blog/ai-agent-failure-modes-detection-playbook)

## Hard rule

**You may not use the words "transient", "flaky", "stale", "orphaned", or
"unrelated" about a check until you have read its failure body and quoted the
actual error.** A duration (e.g. "4s") is a hint, never proof.

## Protocol (in order — do not skip)

1. **Identify the exact failing check + its commit.**
   ```bash
   head=$(gh pr view <N> --json headRefOid -q .headRefOid)
   gh pr checks <N> | grep -viP "\t(pass|skipping)\t"
   ```

2. **Read the failure body. This is the step that gets skipped.**
   - GitHub Actions job: `gh run view --job <id> --log-failed | tail -40`
   - CodeQL / code-scanning: read the ALERTS, not just the check:
     ```bash
     gh api "repos/<owner>/<repo>/code-scanning/alerts?state=open&per_page=100" \
       --jq '.[] | "\(.rule.id) | \(.rule.security_severity_level) | \(.most_recent_instance.location.path):\(.most_recent_instance.location.start_line) | ref=\(.most_recent_instance.ref)"'
     ```
   - Also fetch the check-run's `output.title` / `output.summary` — it usually
     states exactly what failed ("2 new alerts including 2 high severity…").

3. **Classify against branch protection.** Map each REQUIRED context to its real
   state on the head commit, so you know what actually blocks:
   ```bash
   gh api repos/<owner>/<repo>/branches/main/protection/required_status_checks -q '.contexts[]'
   gh api "repos/<owner>/<repo>/commits/$head/check-runs" --paginate \
     -q '.check_runs[] | "\(.name)=\(.conclusion)"'
   ```

4. **THEN form a hypothesis,** and only with one of these supported verdicts:
   - **REAL** — the body shows a genuine defect → fix the code, add a test.
   - **PRE-EXISTING** — same alert exists on `main` independent of your diff
     (prove it: query alerts on `refs/heads/main`). Diff-attributed but not yours;
     still must be fixed to unblock — fix it or get an explicit dismissal decision.
   - **INFRA** — the *log* shows a runner/network/quota error (quote the line).
     Only now may you re-run. "It was fast" is not an INFRA verdict.

5. **Re-run only after an INFRA verdict** with a quoted log line. Re-running a
   green-workflow-but-red-check loop forever does nothing if the real blocker is a
   pinned failed check-run from a prior commit — push a fresh commit instead.

## "Are you sure?" interaction

If the CEO asks "are you sure?" about a CI claim, your triage was superficial.
Re-run this protocol from step 2 (read the body) before answering. See
`evidence-first-answer`.

## Anti-patterns

| Pattern | Fix |
|---|---|
| "CodeQL failed in 4s — transient, re-running" | Read `output.summary` + alerts first; 4s ≠ proof |
| Resolving a review/scan thread to clear a gate | Address the finding in code; resolving ≠ fixing |
| Re-running a failed check repeatedly with no log read | One read; classify REAL/PRE-EXISTING/INFRA; act on the class |
| "Unrelated to my change" without checking main | Query alerts on `refs/heads/main` to prove pre-existing |

## Exit criteria

Every red required check is classified with quoted evidence and either fixed
(REAL/PRE-EXISTING) or re-run after a quoted INFRA log line. Never declare CI green
without `gh pr checks` showing it.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.