ci-debug

# /ci-debug — classify a failing CI run Direct response to the recurring CI-debug pattern surfaced by `/insights`: ~12 sessions in 3 weeks doing the same classification dance. This skill encodes the 11 patterns so the dance becomes a lookup. ## Input User invokes with one of: - **PR number**: `/ci-debug 822` (default repo from context; ask if ambiguous) - **Run URL**: `/ci-debug https://github.com/owner/repo/actions/runs/12345` - **Job URL**: `/ci-debug https://github.com/owner/repo/actions/runs/X/job/Y` ## Execution ### 1. Resolve the failing job ```bash # From PR number: gh pr checks <n> --repo <owner>/<repo> --json bucket,link,name \ --jq '.[] | select(.bucket=="fail") | "\(.name)|\(.link)"' # From run URL: gh api repos/<owner>/<repo>/actions/runs/<run-id>/jobs \ --jq '.jobs[] | select(.conclusion=="failure") | {id, name, runner_name, started_at, completed_at, steps: [.steps[] | select(.conclusion=="failure") | {name, number}]}' ``` If multiple jobs failed, pick the one with the **shortest duration** — root cause is usually the first failure; later jobs cascade. **No job in the `fail` bucket but a check won't settle?** If `gh pr checks` shows zero `fail`-bucket entries yet a status sits in `pending` that never resolves (and `gh pr view --json mergeStateStatus` returns `UNSTABLE` while `mergeable=MERGEABLE`), this is a *stuck external status*, not a failure — jump straight to **Pattern #11**. There is no failing log to fetch;...