ci-triage

Diagnose failing GitHub CI checks and drive root-cause fixes to green.

64|11|Updated May 24, 2026
One-click install
npx skills add https://github.com/AlexanderMattTurner/agent-glovebox --skill ci-triage-alexandermattturner
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ci-triage
Source: https://github.com/AlexanderMattTurner/agent-glovebox/tree/main/.claude/skills/ci-triage
Command: npx skills add https://github.com/AlexanderMattTurner/agent-glovebox --skill ci-triage-alexandermattturner

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a CI check goes red, teams waste time re-running jobs, dismissing failures as flakes, or misreading GitHub check state. This Skill enforces a disciplined workflow: read the actual failing log, diagnose to root cause, and push a real fix instead of guessing or blindly re-running. ## Core Features & Use Cases - Root-cause doctrine for red checks: Treats every failure as a real bug until the log proves otherwise, forbidding opening assumptions like "flake", "pre-existing", or "infra" and requiring root-cause fixes even for proven flakes. - GitHub check-state reading: Covers how to read PR check status correctly with gh versus mcp__github__* tools, including pagination traps, mergeable_state interpretation, draft-PR deferred suites, and timeout-versus-cancellation detection. - Deduplication and claim coordination: Searches issues and PRs before fixing shared reds, files claim issues to prevent duplicate work across sessions, and batches one fix push per round to avoid cancelling in-flight runs. - Use Case: A PR shows a red check after a webhook notification. Instead of re-running the job, you read the failing step's log excerpt, identify a race condition in a test, dispatch a subagent to fix it at the root, and verify the whole round goes green. ## Quick Start Ask the assistant to diagnose why the CI check on my pull request is failing and fix the root cause instead of re-running it.

Frequently Asked Questions about ci-triage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I diagnose a failing GitHub Actions check?▼

Start by reading only the failing steps with gh run view --log-failed or get_job_logs with failed_only, never the full job log. Diagnose the failure to its specific root mechanism before attempting any fix, and never treat a re-run as a solution.

Should I re-run a flaky CI test or fix it?▼

Fix it. A proven flake obligates a root-cause fix such as making the test deterministic or adding retry and backoff, never a mute, skip, or bare re-run. A re-run is only permitted alongside an already in-flight root-cause fix.

Why does gh fail with 403 in a Claude Code web session?▼

Web sessions proxy GitHub access, so GraphQL calls like gh pr list and REST write paths return 403 while REST reads still work. Probe with gh api repos/{owner}/{repo} first, then use mcp__github__ tools for what REST cannot reach.

Can one page of get_check_runs prove a PR is all green?▼

No. The check-runs endpoint is paginated and a PR can have more runs than one page holds, so a failing check may sit on an unread page. Read the aggregate mergeable_state or page to the end before claiming green.

Why does a cancelled job with no error mean a timeout?▼

GitHub reports jobs exceeding timeout-minutes as cancelled, showing only an operation-canceled error in the step log. Compare the job duration against the workflow's timeout-minutes; a match means timeout, and the fix is making the slow segment cheaper.