Skip to main content
skill CX Codex

parallel-ci-triage — Claude Code skill: fix failed CI jobs

Splits failed GitHub Actions jobs across parallel subagents, each fixing its own slice. Useful when CI breaks in several places at once.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add spencerpauly/awesome-cursor-skills --skill parallel-ci-triage -a claude-code
Open on GitHub

What parallel-ci-triage does

The skill triages a failed GitHub Actions run job by job. You start with gh run list --limit 5, then pull the failed step logs with gh run view <RUN_ID> --log-failed. Every failed job goes to its own generalPurpose subagent, all launched in a single message so they run at the same time.

Each subagent gets the job name, the run URL, the branch and the relevant log excerpt. It infers the root cause from the stack trace, edits only what that job needs, and reruns the failing command locally. The report covers what broke, what changed and whether the local check passes. Two failures with the same root cause in the same file go to one agent, because parallel edits to shared files collide.

You need the GitHub CLI installed and authenticated with gh auth login, plus push access so fixes can be pushed and CI rerun. Without gh, download the logs from the web UI and paste them into the chat. Redact secrets before pasting. A single job with one clear error is faster to fix in the main agent, and flaky infrastructure is a retry, not a triage.

What it helps with

  • triage a failed GitHub Actions run by job
  • fix several independent CI failures in one pass
  • pull failed step logs with gh
  • verify a fix with the same command that failed in CI
  • push changes and watch the new run

Example prompts for the agent

  • CI failed in three jobs — pull the logs and launch a subagent per job
  • Take the latest failed run and fix the lint and e2e jobs in parallel
  • Check the fixes pass locally, commit, then run gh run watch

How to install parallel-ci-triage

1Skills CLI (Vercel)

npx skills add spencerpauly/awesome-cursor-skills --skill parallel-ci-triage -a claude-code

2Manually: put the files in place

~/.claude/skills/parallel-ci-triage/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/parallel-ci-triage/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about parallel-ci-triage

How do I install parallel-ci-triage in Claude?

Run npx skills add spencerpauly/awesome-cursor-skills --skill parallel-ci-triage -a claude-code. The skill lands in ~/.claude/skills/parallel-ci-triage/SKILL.md.

What does parallel-ci-triage do?

It fetches failed GitHub Actions job logs and hands each job to a parallel subagent. Every agent finds the root cause, edits the code and verifies the fix locally.

What do I need before using it?

The GitHub CLI installed and authenticated via gh auth login, plus push access to the repo. If gh is unavailable, copy the logs from the web UI and paste them into the chat.

Source text

SKILL.md · CC0-1.0
---
name: parallel-ci-triage
description: When GitHub Actions fails, fetch failing job logs and assign each failing job to a separate subagent that fixes its slice of the problem in parallel. Use for multi-job CI failures where jobs are independent.
user-invocable: true
---

# Parallel CI Triage

Speed up fixing broken CI by splitting failing **jobs** (or independent failure clusters) across parallel subagents. Each subagent owns one vertical slice: logs, root cause, code fix, and local verification for that slice.

## Prerequisites

- **GitHub CLI** (`gh`) installed and authenticated (`gh auth login`), or use the GitHub web UI / API to copy logs manually.
- Push access to the repo so fixes can be pushed and CI re-run.

## Workflow

### 1. Identify the failing run

From the repo root:

```bash
gh run list --limit 5
gh run view <RUN_ID> --log-failed
```

Or open the Actions tab, open the failed workflow run, and note which **jobs** failed (not just which step — group by job name).

If `gh` is unavailable, download logs from the GitHub UI and paste them into the conversation.

### 2. Split by job (or by failure cluster)

- **One subagent per failed job** when jobs test different things (e.g. `lint`, `test-node-18`, `e2e`).
- **One subagent per independent failure cluster** when a single job logs multiple unrelated errors — but prefer one job per agent to avoid conflicting edits in the same files.

If two failures share the same root cause in the same file, assign **one** subagent to fix both.

### 3. Launch parallel subagents

For each failing job, launch a `generalPurpose` subagent in a **single message** so they run concurrently:

```
Task: Fix CI failure for job "<JOB_NAME>"

Context:
- Workflow run: <RUN_URL or RUN_ID>
- Branch: <branch>
- Relevant log excerpt (failed steps only):
<paste gh run view --job <JOB_ID> --log or the failed section>

Instructions:
1. Infer the root cause from the log (command, stack trace, file:line).
2. Open and edit only what this job requires.
3. Run the same commands locally that failed in CI (or the narrowest equivalent, e.g. `npm run lint`, `pytest tests/foo`, `pnpm test --filter pkg`).
4. Report: what failed, what you changed, and confirmation that the local command passes.
```

Include the **exact** failing command and error lines so the subagent does not guess.

### 4. Merge and verify

- Collect each subagent’s changed files. Resolve overlaps manually if two agents touched the same file.
- Run the full CI-equivalent locally when possible:

  ```bash
  # Example: match your repo
  npm run lint && npm test
  ```

- Commit with a conventional message, push, and re-check the workflow:

  ```bash
  gh run watch
  ```

## When to use

- Multiple GitHub Actions jobs failed and the failures look independent.
- A long workflow log is easier to split by job than to fix sequentially.

## When not to use

- A single job with one clear error — fix it in the main agent.
- Failures that are purely flaky infrastructure — retry or fix workflow config first.

## Notes

- Redact secrets if pasting logs into chat.
- If agents conflict on shared files, merge sequentially after the parallel pass.

© spencerpauly · CC0-1.0 · spencerpauly/awesome-cursor-skills

Similar skills

All skills for DevOps and infrastructure →

From the same set64

python-tdd-with-uv Runs your agent through red-green-refactor in Python and sets the project up on uv. Useful when tests come before the code. CX Codex +1 409installs recording-browser-flow-as-test Walks through browser interactions step by step via MCP and outputs a clean Playwright test based on accessibility tree selectors. CX Codex +1 406installs verifying-markdown-formatting Walks a Markdown file through a formatting checklist and fixes what it finds: headings, lists, links, code blocks, spacing. Useful before committing a README or docs. CX Codex +1 404installs exporting-to-png Teaches the agent to render code snippets, Mermaid diagrams, terminal logs, and SVG files into PNG images via CLI utilities or headless browsers. CX Codex +1 401installs screenshotting-changelog Builds a visual changelog for a pull request: captures pages before and after your UI edits and drops the image pairs into the PR body. CX Codex +1 401installs updating-npm-package Updates npm dependencies safely by checking npmjs.com and adapting to the version jump. It runs tests on minor updates and finds migration guides for major ones. CX Codex +1 398installs react-native-patterns This skill guides an agent building React Native and Expo apps, covering navigation, platform-specific code, styling, lists, and native modules. CX Codex +1 399installs adding-docker This skill writes a Dockerfile, docker-compose setup and .dockerignore for your app. Useful when you want a container without hand-writing the configs. CX Codex +1 398installs

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor