parallel-ci-triage
Skill2 starsChanged 6 months agoMITView on GitHub
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. Use when the user says "/parallel-ci-triage", "parallel ci triage", or asks about parallel ci triage.
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 29
If gh is unavailable, download logs from the GitHub UI and paste them into the conversation.
- Very specific: line 33
One subagent per failed job: when jobs test different things (e.g.
- Distinctive: line 34
One subagent per independent failure cluster: when a single job logs multiple unrelated errors — but prefer one job per agent to avoid …
- Distinctive: line 36
If two failures share the same root cause in the same file, assign one subagent to fix both.
- Distinctive: line 63
Run the full CI-equivalent locally when possible:
- Distinctive: line 70
Commit with a conventional message, push, and re-check the workflow:
- Distinctive: line 89
If agents conflict on shared files, merge sequentially after the parallel pass.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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:
gh run list --limit 5
gh run view <RUN_ID> --log-failedOr 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:
# Example: match your repo npm run lint && npm testCommit with a conventional message, push, and re-check the workflow:
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.
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 2
- ZeroTokenClaw/agents-skills★ 199% same
- matarpeles/skills-registry-demo★ 099% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository85 other files it gives its agents.
- accessibility-auditingSkill
- adding-analyticsSkill
- adding-api-docsSkill
- adding-authSkill
- adding-dockerSkill
- adding-e2e-testsSkill
- adding-error-trackingSkill
- adding-feature-flagsSkill
- adding-stripeSkill
- api-smoke-testingSkill
- architecture-decision-recordsSkill
- auditing-performanceSkill
- auditing-securitySkill
- auto-type-checkingSkill
- babysitting-prSkill
- best-of-n-solvingSkill
- building-skills-from-patternsSkill
- cavemanSkill
- codebase-onboardingSkill
- comparing-branches-visuallySkill
- converting-css-modules-to-tailwindSkill
- converting-css-to-tailwindSkill
- creating-prSkill
- dark-mode-testingSkill
- database-designSkill
- design-an-interfaceSkill
- detecting-port-conflictsSkill
- domain-modelSkill
- edit-articleSkill
- exporting-to-pngSkill
- finding-dev-server-urlSkill
- fixing-broken-linksSkill
- form-testingSkill
- generating-imagesSkill
- git-guardrails-claude-codeSkill
- github-triageSkill
- grill-meSkill
- grinding-until-passSkill
- improve-codebase-architectureSkill
- incident-responseSkill
- kubernetes-deployingSkill
- migrate-to-shoehornSkill
- monitoring-terminal-errorsSkill
- network-request-auditingSkill
- obsidian-vaultSkill
- parallel-code-reviewSkill
- parallel-exploringSkill
- parallel-test-fixingSkill
- profiling-performanceSkill
- prompt-engineeringSkill
- python-tdd-with-uvSkill
- qaSkill
- react-native-patternsSkill
- recording-browser-flow-as-testSkill
- request-refactor-planSkill
- responsive-testingSkill
- reviewing-codeSkill
- saving-workspace-contextSkill
- scaffold-exercisesSkill
- screenshotting-changelogSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

