/iterative-review

← Vissza az áttekintéshez

Összefoglaló

Több devil's advocate ágenst indít párhuzamosan, hogy átvizsgálják a célt, majd javító ágenseket indít az összes közepes vagy súlyosabb probléma orvoslására, minden javítási kör után újrafuttatja a teszteket, és addig ismétli a folyamatot, amíg egyetlen kritikus, súlyos vagy közepes probléma sem marad.

Mikor használd

Akkor használd a /iterative-review skillt, ha nemcsak átvizsgálást szeretnél, hanem a javításokat is automatikusan, ciklusban alkalmazva — nem csak egy hibalistát. Addig forog a ciklus, amíg minden kritikus, súlyos és közepes probléma eltűnik.

Lényeges különbség a /da-review-hoz képest: a /da-review csak azonosítja a problémákat, majd megáll — magad javítod őket. A /iterative-review automatikusan azonosítja és kijavítja az összes közepes vagy súlyosabb problémát, és minden kör között újrafuttatja a teszteket. Válaszd a /da-review-ot, ha kézben szeretnéd tartani a javításokat; válaszd a /iterative-review-ot, ha azt szeretnéd, hogy a problémák automatikusan megoldódjanak.

Tipikus kiváltó helyzetek:

Meghívás

Add át a célt argumentumként. Ha nem adsz meg argumentumot, a skill az aktuális, commitálatlan változtatásokat vizsgálja (git diff HEAD).

/iterative-review [target]

Paraméterek:

Ciklus viselkedése: Minden kör legalább 3 DA ágenst indít, akik különböző szempontok szerint vizsgálnak (helyesség / peremesetek, architektúra / tervezés, tesztlefedettségi hiányok). A problémákat súlyossággal és ciklus-prefixes azonosítóval címkézi (pl. C1-I-1). A javító ágensek minden Kritikus, Súlyos és Közepes találatot orvosolnak. A ciklus akkor áll meg, ha az összevont problémalistán nincs egyetlen Kritikus, Súlyos vagy Közepes elem sem — vagy ha ugyanazok a gyökérokú problémák körről körre változatlanul újra megjelennek (megoldhatatlan oszcilláció). Ha telepítve van az opcionális /brooks-review parancs (Brooks-Lint), minden kör egy Brooks-Lint vizsgálót is indít, amelynek találatait — C1-B-1, C1-B-2, … címkékkel — a DA találatokkal együtt vonja össze és javítja; a parancs induláskor ellenőrzi, és jelzi, hogy megtalálta-e a /brooks-review-ot, vagy csak a DA ágensekkel folytatja.

Clean code katalógus futás (csak az 1. körben): Ha a /clean-code-review telepítve van és a cél kód (nem commitolt változások, git ref/range vagy forrásfájl-útvonalak), az 1. kör egy /clean-code-review futást is elvégez — 132 strukturált ellenőrzés 7 csoportban, a találatok C1-CC-1, C1-CC-2, … címkével, a többivel együtt javítva. Egy frissen indított saját general-purpose ágensben fut, ugyanabban a párhuzamos csoportban, mint a devil's advocate ágensek: a /clean-code-review maga is egy szétágazó orchestrator, amely 7 csoport-ágenst és egy szintetizálót indít, így ágens-indítási és skill-hívási képességre van szüksége, ami csak a general-purpose ágensnek van meg — ezért nem egy devils-advocate reviewerre van bízva. A későbbi körökben szándékosan nem ismétlődik: a 2. körtől kezdve a hurkot a DA ágensek és a Brooks-Lint reviewer viszik tovább. A parancs induláskor jelzi, hogy fut-e, vagy kihagyja (nincs telepítve, vagy a cél nem kód).

Súlyossági rubrika:

Megjegyzés: A javító ágensek NEM hoznak létre git commitokat — minden változtatás commitálatlan working-tree módosításként marad.

Megjegyzés a folytatásról: Amikor az /implement skillként hívja meg, a hívó skill maga tartalmazza a "ne állj meg a review verdiktnél" emlékeztetőt a 3. lépésében — és az /iterative-review önmaga is minden Review Summary végén elhelyez egy ⚠️ CALLER figyelmeztetést, amely szerint az összefoglaló nem feladat-teljesítési jelzés, és a hívónak azonnal folytatnia kell a következő lépéssel. A hívó és a meghívott skill is hordoz folytatás-emlékeztetőt.

1. példa — Hibák automatikus javítása egy feature diffben (szemléltető példa)

Bemenet:

/iterative-review $(git diff HEAD)

Kimenet / Eredmény (2 kör után):

## Cycle 1 — DA findings (3 agents)
Critical C1-I-1: `save_order()` called before payment confirmed — order can be
  saved without charge.
Major    C1-I-2: No rollback on partial failure between charge and order save.
Moderate C1-I-3: Retry count hardcoded to 3; should be env-configurable.

## Cycle 1 — Fixes applied
C1-I-1 fixed: moved `save_order()` call after payment confirmation check.
C1-I-2 fixed: added try/finally block with rollback on charge success + save failure.
C1-I-3 fixed: replaced magic number with MAX_RETRY env var (default 3).

Tests: 42 passed, 0 failed.

## Cycle 2 — DA findings (3 agents)
(no Critical, Major, or Moderate issues found)

## Review Summary
### Verdict
No critical, major or moderate issues remain.
### Remaining Open Issues
- Minor N1: variable `tmp` in line 47 could be renamed for clarity (not auto-fixed).

2. példa — Egy plan-fájl átvizsgálása és a hiányok pótlása (szemléltető példa)

Bemenet:

/iterative-review plans/FEAT-007-payments.md

Kimenet / Eredmény:

## Cycle 1 — DA findings
Major C1-I-1: Task 3.2 adds a `/refund` endpoint but no task covers updating
  ledger records on refund — creates an inconsistency in accounting reports.
Major C1-I-2: No rollback task defined if the DB migration in Task 4.1 fails.
Moderate C1-I-3: Acceptance criteria for Task 2.3 omit rate-limiting the
  charge endpoint.

## Cycle 1 — Fixes applied
C1-I-1 fixed: added Task 3.3 "Update ledger on refund" to the plan.
C1-I-2 fixed: added Task 4.2 "Rollback plan for DB migration failure".
C1-I-3 fixed: added rate-limit acceptance criterion to Task 2.3.

## Cycle 2 — DA findings
(no Critical, Major, or Moderate issues found)

## Review Summary
### Verdict
No critical, major or moderate issues remain.
### Changes Made
- C1-I-1 → Major → added Task 3.3 to plan
- C1-I-2 → Major → added Task 4.2 to plan
- C1-I-3 → Moderate → tightened Task 2.3 acceptance criteria

Kapcsolódó eszközök