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.
Installs into .claude/skills of the current project.
Are you the author of Parallel Ci Triage?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/0xaidan-parallel-ci-triage)
---
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.