Diagnose ci

Skill urmzd/dotfiles/dot_agents/skills/diagnose-ci

Cross-platform dotfiles managed by Chezmoi with Homebrew/apt and per-language version managers. One-command bootstrap for macOS and Linux with Neovim, Tmux, Zsh, and AI agent skills.

Install

npx -y skills add urmzd/dotfiles --skill diagnose-ci

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Investigate failing REMOTE CI runs on GitHub Actions: find the failed run, pull the failed-step logs with gh, identify the root cause (compile error, test failure, lint, missing secret, timeout), and recommend a fix. Read-only: it does not commit, push, or edit. Use when CI is red, a GitHub Actions run failed, or the user asks "why did the pipeline fail". Do NOT use for local build/test/runtime failures on your machine (use diagnose-runtime); do NOT apply the fix and re-ship (use fix-and-retry) -- this skill investigates and recommends only.

SKILL.md

2.6 KB, as published. Nobody here has run it

Diagnose CI

Investigate and diagnose CI pipeline failures.

Steps

Find the failure:
- If a run_id is provided, use gh run view <run_id> --log-failed.
- Otherwise, run gh run list --status=failure --limit 5 --json databaseId,name,headBranch,conclusion,createdAt to find recent failures.
- Pick the most recent failure on the current branch (or the most recent overall if none match).
Pull logs: Run gh run view <id> --log-failed to get the failed step logs. If output is large, focus on the last 100 lines of the failing step.
Diagnose: Analyze the logs to identify:
- The specific step that failed
- The root cause (compile error, test failure, lint issue, missing secret, timeout, etc.)
- The relevant file(s) and line(s) if applicable
Recommend fix: Based on the diagnosis (read-only: recommend, do not apply):
- If it's a code issue: show the exact fix and point the user to fix-and-retry to apply + re-ship it.
- If it's a config issue (missing secret, wrong action version): explain what to change.
- If it's flaky (timeout, network): suggest re-running with gh run rerun <id>.

Report: Present a concise summary:

## CI Failure: <workflow name> (run #<id>)
- Branch: <branch>
- Failed step: <step name>
- Root cause: <explanation>
- Fix: <what to do>

Rules

Always check the current repo's workflows first (gh run list).
If gh is not authenticated or the repo has no remote, report that clearly.
Don't blindly re-run failed pipelines; diagnose first.

Gotchas

gh run view <id> --log-failed returns empty for a cancelled run (no step is marked "failed", so there is nothing to dump). Fall back to gh run view <id> --json jobs and inspect each job's conclusion/steps to find the cancelled or failed step, then read its log directly.