diagnose-ci-failures
warpdotdev/common-skills
Diagnose CI failures for a PR, extract error logs, and generate a fix plan using GitHub CLI.
What is diagnose-ci-failures?
This skill checks CI status for a PR, extracts failure logs from failed checks, categorizes errors by type, and generates a plan document to fix them. Use it when investigating PR build failures, test failures, or CI issues without making code changes directly.
- Verifies a PR exists for the current branch
- Fetches CI status and identifies failed, passing, and in-progress checks
- Extracts failure logs from failed CI runs using GitHub CLI
- Categorizes errors by type: formatting, linting, compilation, tests, and platform-specific issues
- Generates a plan document with problem statement, current state, proposed fixes, and validation steps
- Cross-references the fix-errors skill for detailed error resolution guidance
How to install diagnose-ci-failures
npx skills add https://github.com/warpdotdev/common-skills --skill diagnose-ci-failures- GitHub CLI (gh) installed and authenticated
- Git repository with remote tracking a GitHub repository
- An existing pull request for the current branch (or ability to create one)
How to use diagnose-ci-failures
- 1.Run the skill to check the current branch and verify a PR exists
- 2.The skill fetches CI status and identifies which checks have failed, passed, or are in progress
- 3.If CI is still running, review which checks have already failed and wait for completion if needed
- 4.The skill extracts logs from all failed checks and categorizes errors by type
- 5.Review the generated plan document that summarizes the problem, current state, and proposed fixes
- 6.Use the plan to guide your fixes, referencing the fix-errors skill for specific error types
Use cases
- A PR has failing CI checks and you need to understand what went wrong before fixing
- Multiple CI checks failed across different platforms (macOS, Linux, Windows) and you need to triage them
- Test failures in CI need investigation to determine root causes and create a fix strategy
- A developer wants to see a structured plan of all CI issues before starting code changes
- Platform-specific failures (WASM, Windows-only issues) need to be identified and categorized
- Software engineers debugging CI/CD pipeline failures
- Developers triaging test failures in pull requests
- DevOps engineers investigating build system issues
- Team leads reviewing CI status before merging PRs
diagnose-ci-failures FAQ
The skill will inform you and offer to create one using the create-pr skill.
The skill will show you which checks have already failed or passed and suggest waiting for all checks to complete before full diagnosis.
No. It only generates a plan document for review. Code changes are made separately using other skills like fix-errors.
It categorizes errors into groups (formatting, linting, compilation, tests, platform-specific) and recommends fixing one category at a time.
The skill focuses on CI results. Local failures may be environment-specific or flaky; verify CI status first before flagging as issues.
Full instructions (SKILL.md)
Source of truth, from warpdotdev/common-skills.
name: diagnose-ci-failures description: Diagnose CI failures for a PR using the GitHub CLI, extract error logs, and generate a plan to fix them. Use when the user asks to check CI status, pull CI issues, triage test failures, or investigate PR build 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:
# Get current branch
git branch --show-current
# Check for PR
GH_PAGER=cat gh 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:
GH_PAGER=cat 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:
GH_PAGER=cat 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 fmtfailures - Linting issues:
cargo clippywarnings/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
- GitHub CLI paging: Set
GH_PAGER=caton everyghinvocation. The GitHub CLI does not support--no-pageras a global option;GH_PAGERandPAGERare its documented paging controls - 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-errorsskill
Common CI Check Names
Formatting + Clippy (MacOS)Formatting + Clippy (Linux)Run MacOS testsRun Linux testsRun Windows testsCheck CI results(summary check)WASM build
Example Commands
Get PR status with details:
GH_PAGER=cat gh pr view --json number,title,state,statusCheckRollup
Get logs from specific failed run:
GH_PAGER=cat gh run view 12345678 --log-failed
Check for specific error in logs:
GH_PAGER=cat gh run view 12345678 --log-failed 2>&1 | grep -A 5 "error:"
Related skills
More from warpdotdev/common-skills and the wider catalog.

fix-errors
Fix Rust compilation errors, linting issues, and test failures in the warp codebase.

implement-specs
Implement approved features while keeping PRODUCT.md and TECH.md synchronized with code in a single PR.

migrate-to-factory
Migrate existing skills and workflows into a Warp Factory configuration repository.

pr-walkthrough
Generate interactive D3 visualizations to orient reviewers to pull request changes across system, data flow, dependencies, and user actions.

readout
Generate polished, self-contained HTML readout documents from conversation findings or fresh research.

reproduce-bug-report
Launch cloud agents with computer use to reproduce UI bugs and capture visual evidence.