Przejdź do treści
Biblioteka skilli
DevOps i chmura · Automatyzacja

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.

Repozytorium
agent-skills ↗
Licencja
MIT
Ostatnia zmiana repozytorium
24.10.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
1
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 24.10.2026, bez odwołań do wycofanych modeli i API.

Licencja

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

fix CImake tests passdiagnose CI failuresdrive this to green
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

  1. Inputs
  2. Workflow
  3. Chaining
Sekcje z nagłówków SKILL.md, w oryginale · 178 linii, 847 słów
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

RepozytoriumWynikLicencja
Ta strona · oleg-koval/agent-skills100MIT
oleg-koval/agent-skills100MIT

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.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.