parallel-ci-triage
/parallel-ci-triage
Pobiera logi nieudanych zadań GitHub Actions i przydziela każde zadanie osobnemu subagentowi, który równolegle naprawia swój fragment problemu.
- Autor
- spencerpauly ↗
- Repozytorium
- awesome-cursor-skills ↗
- Licencja
- CC0-1.0
- Ostatnia zmiana repozytorium
- 01.08.2026
Ocena i bezpieczeństwo
- Pliki w paczce
- 1
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 0
Brak sygnałów. Repozytorium zmienione 01.08.2026, bez odwołań do wycofanych modeli i API.
CC0-1.0, otwarta.
Co robi i kiedy
Pobiera logi nieudanych zadań GitHub Actions i przydziela każde zadanie osobnemu subagentowi, który równolegle naprawia swój fragment problemu.
Oryginalny opis (EN)
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.
Jak działa
- Prerequisites
- Workflow
- When to use
- When not to use
- Notes
Podgląd SKILL.md
--- 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.
Wersje
W bazie nie ma innych skilli o nazwie parallel-ci-triage.
Migawka bazy z 28.10.2026 · wersja paczki ae03cd169185 (skrót SHA-256 całej paczki)
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 100github-actions-debugger
Debuguje i monitoruje przebiegi workflowów GitHub Actions: sprawdza status, pokazuje logi nieudanych zadań i wskazuje przyczynę awarii CI. - 100fix-failing-actions
Diagnozuje i naprawia nieudane workflowy GitHub Actions w repozytorium drift: błędy CI, kontroli higieny bezpieczeństwa i workflowu wydań. - 100verify-pr-logs
Sprawdza logi CI GitHub Actions w pull requeście, diagnozuje porażki i prowadzi agenta przez wdrożenie poprawek, ograniczając się do analizy CI danego PR. - 100gh-fix-ci
Sprawdza checki pull requesta przez gh, pobiera logi nieudanych GitHub Actions, streszcza przyczyny, układa plan naprawy i wdraża go po zatwierdzeniu użytkownika. - 100mcore-create-issue
Bada nieudane uruchomienie GitHub Actions i tworzy zgłoszenie GitHub z opisem awarii na podstawie adresu URL przebiegu lub zadania. - 95ci-test-failures
Pomaga diagnozować błędy testów w GitHub Actions, wyciągać nieudane testy z przebiegów, pobierać logi i tworzyć lub aktualizować zgłoszenia o niedziałających testach.