Agent skill · software engineering · microsoft
fix-ci-failures
Investigate and fix CI failures on a pull request. Use when CI checks fail on a PR branch — covers finding the PR, identifying failed checks, downloading logs and artifacts, extracting the failure cause, and iterating on a fix. Requires the `gh` CLI.
Why this skill is useful
Adds specific commands and workflows for diagnosing and fixing CI failures using the `gh` CLI that the AI wouldn't reliably generate on its own.
What it needs
Requires gh installed locally. About 7k tokens when loaded. Last updated 2026-08-07. 188,455 stars on the source repository.
What this skill does
Investigating and Fixing CI Failures This skill guides you through diagnosing and fixing CI failures on a PR using the gh CLI. The user has the PR branch checked out locally. Workflow Overview 1. Identify the current branch and its PR 2. Check CI status and find failed checks 3. Download logs for failed jobs 4. Extract and understand the failure 5. Fix the issue and push --- Step 1: Identify the Branch and PR If no PR is found, the user may need to specify the PR number. --- Step 2: Check CI Status The link field contains the URL to the GitHub Actions job. Extract the run ID from the URL — it's the number after /runs/: If checks are still INPROGRESS, wait for them to complete before downloading logs: --- Step 3: Get Failed Job Details --- Step 4: Download Failure Logs There are two approaches depending on the type of failure. Option A: View Failed Step Logs Directly Best for build/compile/lint failures where the error is in the step output: Important: --log-failed requires the entire run to complete, not just the failed job. If other jobs are still running, this command will block or error. Use Option C below to get logs for a completed job while the run is still in progress. The output can be large. Pipe through tail or grep to focus: Option B: Download Artifacts Best for integration test failures where detailed logs (terminal logs, ext host logs, crash dumps) are uploaded as artifacts: Tip: The <test-type> is the ARTIFACTNAME in the env of the failed job in .github/workflows/pr-<linux win32>-test.yml (e.g., "Linux / Electron (extension host)" → electron-extension-host, "Linux / Remote (integration)" → remote). Map the platform with "Windows" → windows-x64, "Linux" → linux-x64. Warning: Log artifacts may be empty if the test runner crashed before producing output (e.g., Electron download failure). In that case, fall back to Option C. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills microsoft/fix-ci-failures