diagnose-ci-failures
installsforks
How to install diagnose-ci-failures?
warpdotdev/common-skills/diagnose-ci-failures
$npx -y skills add warpdotdev/common-skills --skill diagnose-ci-failuresdiagnose-ci-failures is an agent skill published from warpdotdev/common-skills, installable through the skills CLI.
SKILL.md
| 1 | # diagnose-ci-failures |
| 2 | |
| 3 | Programmatically diagnose CI failures for a PR and generate a plan to fix them. |
| 4 | |
| 5 | ## Overview |
| 6 | |
| 7 | 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. |
| 8 | |
| 9 | ## Workflow |
| 10 | |
| 11 | ### 1. Verify PR exists for current branch |
| 12 | |
| 13 | Get the current branch and check if a PR exists: |
| 14 | |
| 15 | ```bash |
| 16 | # Get current branch |
| 17 | git branch --show-current |
| 18 | |
| 19 | # Check for PR |
| 20 | gh --no-pager pr view <branch-name> --json number,title,url,state |
| 21 | ``` |
| 22 | |
| 23 | If no PR exists, inform the user and offer to create one using the `create-pr` skill. |
| 24 | |
| 25 | ### 2. Check CI status |
| 26 | |
| 27 | Fetch the status of all CI checks: |
| 28 | |
| 29 | ```bash |
| 30 | gh pr view <branch-name> --json statusCheckRollup |
| 31 | ``` |
| 32 | |
| 33 | Parse the output to identify: |
| 34 | - Completed checks vs. in-progress checks |
| 35 | - Successful checks |
| 36 | - Failed checks with their names and details URLs |
| 37 | |
| 38 | 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. |
| 39 | |
| 40 | ### 3. Extract failure logs |
| 41 | |
| 42 | For each failed check, pull the logs using the run ID from the status check: |
| 43 | |
| 44 | ```bash |
| 45 | gh run view <run-id> --log-failed |
| 46 | ``` |
| 47 | |
| 48 | Focus on extracting: |
| 49 | - Error messages and their locations (file paths, line numbers) |
| 50 | - Compilation errors (unused imports, type mismatches, etc.) |
| 51 | - Linting/clippy errors with specific lint names |
| 52 | - Test failure messages and stack traces |
| 53 | - Build failures and their root causes |
| 54 | |
| 55 | ### 4. Categorize errors |
| 56 | |
| 57 | Group errors by type: |
| 58 | - **Formatting issues**: `cargo fmt` failures |
| 59 | - **Linting issues**: `cargo clippy` warnings/errors |
| 60 | - **Compilation errors**: Type errors, missing imports, signature mismatches |
| 61 | - **Test failures**: Failing tests with their names and failure reasons |
| 62 | - **Platform-specific issues**: WASM, Linux, macOS, Windows-specific failures |
| 63 | |
| 64 | ### 5. Generate fix plan |
| 65 | |
| 66 | Create a plan document (using `create_plan` tool) with: |
| 67 | - **Problem Statement**: Summary of failing checks |
| 68 | - **Current State**: What errors were found and where |
| 69 | - **Proposed Changes**: Specific fixes needed for each error category |
| 70 | - **Validation Steps**: Commands to verify fixes (fmt, clippy, tests, presubmit) |
| 71 | |
| 72 | The plan should reference the `fix-errors` skill for detailed guidance on resolving specific error types. |
| 73 | |
| 74 | ## Important Notes |
| 75 | |
| 76 | - **Always create a plan first**: Never make code changes directly. Generate a plan for user review |
| 77 | - **Check test status in CI**: Even if tests fail locally, verify they passed in CI before flagging as issues |
| 78 | - **Unrelated test failures**: If tests passed in CI but fail locally, they may be environment-specific or flaky |
| 79 | - **Multiple error types**: Fix one category at a time (e.g., all clippy errors before tests) |
| 80 | - **Cross-reference fix-errors skill**: For detailed error resolution strategies, use the `fix-errors` skill |
| 81 | |
| 82 | ## Common CI Check Names |
| 83 | |
| 84 | - `Formatting + Clippy (MacOS)` |
| 85 | - `Formatting + Clippy (Linux)` |
| 86 | - `Run MacOS tests` |
| 87 | - `Run Linux tests` |
| 88 | - `Run Windows tests` |
| 89 | - `Check CI results` (summary check) |
| 90 | - `WASM build` |
| 91 | |
| 92 | ## Example Commands |
| 93 | |
| 94 | **Get PR status with details:** |
| 95 | ```bash |
| 96 | gh --no-pager pr view --json number,title,state,statusCheckRollup |
| 97 | ``` |
| 98 | |
| 99 | **Get logs from specific failed run:** |
| 100 | ```bash |
| 101 | gh run view 12345678 --log-failed |
| 102 | ``` |
| 103 | |
| 104 | **Check for specific error in logs:** |
| 105 | ```bash |
| 106 | gh run view 12345678 --log-failed 2>&1 | grep -A 5 "error:" |
| 107 | ``` |
People who liked this also viewed
6 picksType
- azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026
- systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026
- safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026
- explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026
- minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026
- insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 2026
