ci-fix-loop
/ci-fix-loop
Diagnozuje awarie CI w GitHub Actions w pętli: pobiera logi, znajduje przyczynę, stosuje celową poprawkę, pushuje i czeka na kolejny przebieg, aż wszystkie checki zazielenieją lub potrzebny jest człowiek.
- Autor
- oleg-koval ↗
- Repozytorium
- agent-skills ↗
- Licencja
- MIT
- Ostatnia zmiana repozytorium
- 24.10.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 24.10.2026, bez odwołań do wycofanych modeli i API.
MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.
Co robi i kiedy
Diagnozuje awarie CI w GitHub Actions w pętli: pobiera logi, znajduje przyczynę, stosuje celową poprawkę, pushuje i czeka na kolejny przebieg, aż wszystkie checki zazielenieją lub potrzebny jest człowiek.
Wyzwalacze z opisu
Oryginalny opis (EN)
Diagnose GitHub Actions CI failures in a loop: fetch the failing check logs, identify the root cause, apply a targeted fix, push, and wait for the next run: repeating until all checks are green or a real blocker needs a human. Use when CI is red after a push, when the user says "fix CI", "make tests pass", "diagnose CI failures", or "drive this to green". Direct analog of qodoloop / coderabbitloop for automated test and lint failures.
Jak działa
- Inputs
- Workflow
- Chaining
Podgląd SKILL.md
---
name: ci-fix-loop
description: >
Diagnose GitHub Actions CI failures in a loop: fetch the failing check logs, identify
the root cause, apply a targeted fix, push, and wait for the next run: repeating until
all checks are green or a real blocker needs a human. Use when CI is red after a push,
when the user says "fix CI", "make tests pass", "diagnose CI failures", or "drive this
to green". Direct analog of qodoloop / coderabbitloop for automated test and lint failures.
license: MIT
allowed-tools: Bash, Read, Write, Edit
compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git and gh (GitHub CLI) authenticated, with a GitHub Actions workflow configured.
metadata:
targets: [_source-only]
author: Oleg Koval
tags:
- github-actions
- ci
- testing
- automation
- loop
- fix
source: weekly-pattern-learner
source_reason: "qodoloop and coderabbitloop share the push→poll→diagnose→fix→repeat loop; CI failures have the same shape but no dedicated skill existed"
source_date: "2026-07-28"
---
> 🤖 *Auto-generated by **weekly-pattern-learner** · qodoloop and coderabbitloop share the push→poll→diagnose→fix→repeat loop; CI failures have the same shape but no dedicated skill existed*
# CI Fix Loop
Drive a GitHub Actions CI run from red to green: fetch failure logs, diagnose, apply
a targeted fix, push, and repeat until all required checks pass or a blocker is hit.
## Inputs
- **PR number** (optional): detect from current branch if not given.
- **Check names** (optional): limit to specific failing checks instead of all.
- **Max iterations** (default: 5)
## Workflow
### 1. Identify the PR and current CI state
```bash
# Detect PR from current branch
gh pr view --json number,headRefName,headRefOid \
-q '{number, branch: .headRefName, sha: .headRefOid}'
# Current check status
gh pr checks --json name,state,conclusion 2>/dev/null \
|| gh run list --branch <branch> --limit 5
```
Classify each check as: `pass`, `fail`, `pending`, or `skipped`.
**Exit immediately if all required checks already pass**: nothing to do.
### 2. Loop (max 5 iterations)
#### A. Identify failing checks
```bash
gh pr checks --json name,state,conclusion \
--jq '.[] | select(.conclusion == "failure" or .state == "FAILURE")'
```
For each failing check, record: check name, workflow file, job name.
Stop if the working set is empty: all required checks are green.
#### B. Check for base-branch regression first
Before touching any code, verify the failure is not already present on `main`:
```bash
gh run list --branch <base-branch> --workflow <workflow-name> --limit 3 \
--json conclusion --jq '.[].conclusion'
```
If the same check is failing on the base branch, **stop and report**:
this is not your PR's fault. Do not attempt a fix that masks a base-branch problem.
Wait for a `Base branch recovered` notice before re-trying.
#### C. Fetch failure logs
For each failing check:
```bash
# Latest run ID for this branch/workflow
gh run list --branch <branch> --workflow <workflow-name> --limit 1 \
--json databaseId --jq '.[0].databaseId'
# Fetch only failing steps (not the full log)
gh run view <run-id> --log-failed
```
Cap log reading at ~200 lines per job: the error is almost always in the last
50 lines of a failed step.
#### D. Diagnose
Classify the failure before writing any code:
| Category | Examples | Fix target |
|---|---|---|
| Test failure | `FAIL TestFoo`, `AssertionError`, `expected X got Y` | Source or test |
| Lint / format | `gofmt`, `eslint`, `ruff`, `prettier` | Run auto-formatter |
| Build error | compile error, missing import, type mismatch | Source |
| Dependency | `npm ERR!`, missing module, lockfile mismatch | Update lockfile |
| CI config | YAML parse error, bad action ref, missing secret | Workflow YAML |
| Flaky test | same test passes on manual re-run | Re-run first; mark if it keeps failing |
For flaky-looking failures, re-run the check before touching code:
```bash
gh run rerun <run-id> --failed
```
Wait for the rerun result. If it passes on rerun, skip this iteration and go to
step F to poll for the new result.
#### E. Apply a targeted fix
Fix **only** what the log names as the failure. Do not refactor surrounding code,
add unrelated tests, or touch files the failing step never mentioned.
Common one-liners:
```bash
# Go format
gofmt -w .
goimports -w .
# Node format / lint
npx prettier --write .
npx eslint --fix .
# Python
ruff check --fix .
black .
# Lockfile
npm install # Node
poetry lock --no-update # Python
go mod tidy # Go
```
For test failures: read the failing test and the code it exercises. Fix the code
or the assertion, but not both in one commit unless the test was clearly wrong
and the fix is trivial.
#### F. Commit and push
Stage **only the files touched in step E**: never `git add -A`, which can sweep
in unrelated local changes:
```bash
git add <files touched>
git commit -m "fix(ci): <what was broken> (ci-fix-loop iteration N)"
git push
```
Confirm the push succeeded before polling. A resolved check whose fix never reached
the branch is worse than an unresolved one.
#### G. Wait for CI on the new SHA
Poll every ~15s (timeout ~8min) for all previously-failing checks to complete
on the new push:
```bash
gh pr checks --json name,state,conclusion,startedAt
```
Wait until all previously-failing checks show a new result (`pass` or `fail`)
on the current SHA. Do not act on a result that still shows the old SHA.
Go back to step A.
### 3. Report
| Field | Value |
|---|---|
| Iterations | N |
| Checks fixed | names + root cause |
| Checks blocked | names + reason (flaky / needs human / base-branch red) |
| Final status | all green / partial / blocked |
```
CI fix loop complete.
Iterations: 2
Fixed: lint (gofmt: 3 files), test (TestUserCreate: nil pointer in fixture)
Blocked: none
Status: all required checks green
```
## Chaining
| Before this skill | After this skill |
|---|---|
| `olko:pr-description-writer` | `olko:qodoloop` |
| Any `git push` with failing CI | `olko:coderabbitloop` |
Wersje
| Repozytorium | Wynik | Licencja |
|---|---|---|
| Ta strona · oleg-koval/agent-skills | 100 | MIT |
| oleg-koval/agent-skills | 100 | MIT |
Migawka bazy z 13.11.2026 · wersja paczki 97a3b067d460 (skrót SHA-256 całej paczki)
Pobrania w ostatnich 30 dniach: 0 · ranking
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 100ci-debug-loop
Obserwuje przebieg GitHub Actions, diagnozuje awarie z logów, stosuje poprawki i ponownie pushuje, aż CI zazielenieje lub trzeba eskalować. - 100actions-debugging
Diagnozuje nieudane uruchomienie workflow GitHub Actions: czyta log, znajduje przyczynę źródłową i stosuje celową poprawkę. - 90pb-ci-fix
Naprawia czerwone CI lub konfiguruje GitHub Actions od początku do końca: czyta nieudany przebieg, znajduje przyczynę, poprawia workflow i obserwuje, aż uruchomienie na wypchniętym commicie zzieleni. - 100check-ci
Diagnozuje awarie CI przez analizę logów GitHub Actions, wskazuje przyczyny źródłowe i sugeruje poprawki, gdy workflow się wysypał albo sprawdzenia są czerwone. - 100fix-ci
Diagnozuje i naprawia nieudany przebieg CI: pobiera logi (gh run view --log-failed), odtwarza błąd lokalnie, usuwa przyczynę źródłową i weryfikuje zielony wynik przed pushem i po nim. - 100diagnose-ci-failures
Diagnozuje błędy CI w pull requeście przez GitHub CLI, wyciąga logi błędów i generuje plan naprawy.