diagnose-ci-failures

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.

npx skills add https://github.com/warpdotdev/common-skills --skill 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:

# 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:

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 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:

gh --no-pager pr view --json number,title,state,statusCheckRollup

Get logs from specific failed run:

gh run view 12345678 --log-failed

Check for specific error in logs:

gh run view 12345678 --log-failed 2>&1 | grep -A 5 "error:"

More skills from warpdotdev

council
warpdotdev
Run a model-diverse subagent council to investigate the same problem from multiple perspectives, compare findings, and produce a final recommendation. Use this skill whenever the user asks for a council, second opinions, multiple agents/models to evaluate one question, parallel investigation, red-team/blue-team comparison, or help deciding between competing technical approaches.
researchcommunicationproject-management
spec-driven-implementation
warpdotdev
Drive a spec-first workflow for substantial features by writing PRODUCT.md before implementation, writing TECH.md when warranted, and keeping both specs updated as implementation evolves. Use when starting a significant feature, planning agent-driven implementation, or when the user wants product and tech specs checked into source control.
developmentdocumentproject-management
review-pr
warpdotdev
Review a pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a checked-out PR from local artifacts like pr_diff.txt and pr_description.txt and producing machine-readable review output instead of posting directly to GitHub.
code-reviewdevelopment
create-pr
warpdotdev
Create a pull request in the warp repository for the current branch. Use when the user mentions opening a PR, creating a pull request, submitting changes for review, or preparing code for merge.
developmentcode-review
implement-specs
warpdotdev
Implement an approved feature from PRODUCT.md and TECH.md, keeping specs and code aligned in the same PR as implementation evolves. Use after the product and tech specs are approved and the next step is building the feature.
developmentcode-reviewapi
cross-critique
warpdotdev
Run a second round on a contested question by circulating each subagent's independent proposal to the other authors and asking for structured pros and cons, then synthesize. Use this skill whenever you have multiple independent proposals or opinions on a contested decision — architecture tradeoffs, code review disagreements, design choices, competing root-cause theories — and want sharper analysis than you'd produce by synthesizing alone. Pairs naturally with the council and research skills;...
resolve-merge-conflicts
warpdotdev
Resolve Git merge conflicts by extracting only unresolved paths, conflict hunks, and compact diffs instead of loading whole files into context. Use when a merge, rebase, cherry-pick, or stash pop stops on conflicts, when `git status` shows unmerged paths, or when files contain conflict markers.
developmentcode-review
brandalf
warpdotdev
Guides creation, revision, and review of Warp- or Oz-branded assets. Use when working on launch pages, docs, HTML/CSS components, UI mockups, prompts, social assets, copy, presentations, or any other branded deliverable that should look and sound unmistakably Warp or Oz.
designcreativemarketing