
Diagnose Ci Failures
Triage failing GitHub Actions (or PR checks) with gh CLI logs and a fix plan before touching code.
Overview
diagnose-ci-failures is an agent skill most often used in Ship testing (also Operate errors) that uses GitHub CLI to inspect PR CI, extract failure logs, and draft a fix plan.
Install
npx skills add https://github.com/warpdotdev/common-skills --skill diagnose-ci-failuresWhat is this skill?
- Deterministic workflow: verify PR on branch → statusCheckRollup → per-run failure logs
- Uses git branch --show-current and gh pr view for PR metadata and check state
- Distinguishes completed, in-progress, and failed checks with run IDs for log extraction
- Produces a reviewable fix plan document—not automatic code changes
- Offers create-pr skill when no PR exists for the current branch
- Three-step core workflow: verify PR → check CI rollup → extract per-failed-check logs
Adoption & trust: 3.5k installs on skills.sh; 18 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your PR checks failed and scrolling Actions logs in the browser is slow—you need a structured diagnosis before changing code.
Who is it for?
GitHub-based repos where you already pushed a branch and want CLI-driven CI triage with planned fixes.
Skip if: Non-GitHub CI, local-only test runs without a PR, or when you want the agent to apply fixes without a reviewed plan first.
When should I use this skill?
User asks to check CI status, pull CI issues, triage test failures, or investigate PR build failures.
What do I get? / Deliverables
You get a fix plan derived from gh status and failure logs; if no PR exists, the agent points you to create-pr next.
- CI status summary
- Extracted failure log excerpts
- Reviewable fix plan (no automatic code changes)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
CI diagnosis is core ship work—tests and checks gate merge and release. Testing subphase covers interpreting failing automated checks and deciding what to fix next.
Where it fits
After push, rollup shows two red jobs—extract logs and list root errors in a fix plan.
Summarize CI failures for reviewers before requesting re-review.
Recurring main-branch check failures diagnosed from the latest PR merge attempt.
New workflow added—first PR fails; map which step and artifact caused the break.
How it compares
Plan-first gh CLI triage—not a generic linter skill or hosted CI SaaS integration.
Common Questions / FAQ
Who is diagnose-ci-failures for?
Indie and solo developers using GitHub PRs who want fast CI failure summaries and a fix plan without immediate blind code patches.
When should I use diagnose-ci-failures?
Use it in Ship when checks fail on your PR, when investigating test or build failures, or in Operate when recurring pipeline errors block releases—especially if the user asks to check CI status, pull CI issues, or triage PR build failures.
Is diagnose-ci-failures safe to install?
It invokes shell, git, and GitHub network APIs via gh; review the Security Audits panel on this Prism page and ensure gh auth scopes match your org policy.
Workflow Chain
Then invoke: create pr
SKILL.md
READMESKILL.md - Diagnose Ci Failures
# diagnose-ci-failures Programmatically diagnose CI failures for a PR and generate a plan to fix them. ## Overview This skill provides a deterministic workflow to check CI status for a PR, extract failure logs, analyze errors, and create a plan (not code changes) to resolve issues. The output is always a plan document that can be reviewed before execution. ## Workflow ### 1. Verify PR exists for current branch Get the current branch and check if a PR exists: ```bash # Get current branch git branch --show-current # Check for PR gh --no-pager pr view <branch-name> --json number,title,url,state ``` If no PR exists, inform the user and offer to create one using the `create-pr` skill. ### 2. Check CI status Fetch the status of all CI checks: ```bash gh pr view <branch-name> --json statusCheckRollup ``` Parse the output to identify: - Completed checks vs. in-progress checks - Successful checks - Failed checks with their names and details URLs If CI is still running, inform the user which checks have already failed or passed, highlight the checks that are still running, and suggest waiting for completion before diagnosis. ### 3. Extract failure logs For each failed check, pull the logs using the run ID from the status check: ```bash gh run view <run-id> --log-failed ``` Focus on extracting: - Error messages and their locations (file paths, line numbers) - Compilation errors (unused imports, type mismatches, etc.) - Linting/clippy errors with specific lint names - Test failure messages and stack traces - Build failures and their root causes ### 4. Categorize errors Group errors by type: - **Formatting issues**: `cargo fmt` failures - **Linting issues**: `cargo clippy` warnings/errors - **Compilation errors**: Type errors, missing imports, signature mismatches - **Test failures**: Failing tests with their names and failure reasons - **Platform-specific issues**: WASM, Linux, macOS, Windows-specific failures ### 5. Generate fix plan Create a plan document (using `create_plan` tool) with: - **Problem Statement**: Summary of failing checks - **Current State**: What errors were found and where - **Proposed Changes**: Specific fixes needed for each error category - **Validation Steps**: Commands to verify fixes (fmt, clippy, tests, presubmit) The plan should reference the `fix-errors` skill for detailed guidance on resolving specific error types. ## Important Notes - **Always create a plan first**: Never make code changes directly. Generate a plan for user review - **Check test status in CI**: Even if tests fail locally, verify they passed in CI before flagging as issues - **Unrelated test failures**: If tests passed in CI but fail locally, they may be environment-specific or flaky - **Multiple error types**: Fix one category at a time (e.g., all clippy errors before tests) - **Cross-reference fix-errors skill**: For detailed error resolution strategies, use the `fix-errors` skill ## Common CI Check Names - `Formatting + Clippy (MacOS)` - `Formatting + Clippy (Linux)` - `Run MacOS tests` - `Run Linux tests` - `Run Windows tests` - `Check CI results` (summary check) - `WASM build` ## Example Commands **Get PR status with details:** ```bash gh --no-pager pr view --json number,title,state,statusCheckRollup ``` **Get logs from specific failed run:** ```bash gh run view 12345678 --log-failed ``` **Check for specific error in logs:** ```bash gh run view 12345678 --log-failed 2>&1 | grep -A 5 "error:" ```