Więcej cykli naraz, sufitem jest review

Recenzja implementacji jako automatyczna bramka: skill uruchamia się w CI na pull requeście, bez pytań i bez edycji kodu. Czyta, analizuje, zapisuje raport i wystawia werdykt - pilnuje jakości dokładnie wtedy, gdy nikt nie patrzy na ręce.

Wejście: pull request + plan zmiany (context/changes/<change-id>/plan.md), znaleziony po konwencji albo z linii Plan: w opisie PR. Wyjście: raport reviews/impl-review.md zacommitowany na branch PR, komentarz z werdyktem i tabelą wymiarów oraz komentarze inline na oflagowanych liniach diffa.

Trzej subagenci pracują równolegle: dryf względem planu (MATCH / DRIFT / MISSING / EXTRA), bezpieczeństwo i zgodność ze wzorcami, pokrycie testami. Potem lint, build i typecheck, oceny PASS / WARNING / FAIL w siedmiu wymiarach i werdykt całości: APPROVED, NEEDS ATTENTION albo REJECTED.

Kontrakt wyjścia jest sztywny:

• marker <!-- IMPL-REVIEW-REPORT --> w pierwszej linii - po nim raport rozpoznają narzędzia triage,
• każde znalezisko niesie pole Decision: PENDING do późniejszej decyzji człowieka,
• commit raportu ma [skip ci], żeby review nie uruchamiał sam siebie w pętli,
• maksymalnie 10 znalezisk, posortowanych od krytycznych.

Skill nie edytuje kodu i nie zadaje pytań - poprawki idą osobnym krokiem po triage. PR bez planu dostaje neutralny komentarz zamiast czerwonego checka. Werdykt REJECTED blokuje merge; obejście istnieje (etykieta impl-review-override), ale to już świadoma decyzja człowieka, nie maszyny.

Autonomiczny brat /10x-implement: wykonuje zatwierdzony plan pod /goal bez żadnej interakcji - w zwykłej sesji albo headless przez claude -p. Każdą decyzję, którą normalnie podejmuje człowiek, zastępuje jawna, spisana polityka; gdy polityki brakuje, wybiera interpretację konserwatywną i ją raportuje.

Wejście: zatwierdzony plan.md z sekcją Progress jako maszyną stanów. Wyjście: commit per etap (Conventional Commits) plus run report - albo uczciwy STOP-blok z tym, czego plan oczekiwał, co zastano, dlaczego to blokuje i skąd wznowić.

Każdy etap przechodzi stały ciąg: kryteria sukcesu z planu → staging dotkniętych plików → deliberate-break check (celowe zepsucie kodu produkcyjnego; test musi spaść - czerwień jest warunkiem zaliczenia) → pełny zestaw testów, lint, typecheck → commit tylko na zielono. Padająca bramka dostaje najwyżej 2 próby naprawy, potem STOP.

Gdy kod nie zgadza się z planem: Minor (przesunięty plik, zmiana nazwy, dryf importu) - adaptuje i raportuje jedną linią; Structural (brakująca zależność, inna architektura, nieistniejące API) - STOP-blok i koniec pracy. W razie wątpliwości rozjazd jest strukturalny: zły STOP kosztuje jedno wznowienie, złe dostosowanie przemyca przeprojektowanie, którego nikt nie zatwierdził.

Wiersze Manual w Progress są poza jurysdykcją maszyny: nigdy ich nie odhacza i nigdy na nich nie blokuje - trafiają na koniec run reportu jako checklista dla człowieka. Naprawa padającej bramki nigdy nie osłabia asercji, nie usuwa testu i nie luzuje reguł lint: kod ma sprostać sprawdzeniu, nie odwrotnie.

Silnik pojedynczego toru: wykonuje zatwierdzony plan z context/changes/<change-id>/plan.md etap po etapie, z weryfikacją i osobnym commitem po każdym etapie. To dokładnie ten cykl powielasz, gdy dokładasz kolejne równoległe tory.

Wejście: plan z sekcją Progress na dole. Wyjście: zaimplementowane etapy - każdy z własnym commitem (Conventional Commits), którego skrócony SHA wraca do odhaczonych wierszy Progress jako dowód, co i kiedy wylądowało.

Sekcja Progress w planie jest jedynym źródłem stanu - bez plików pomocniczych i markerów. „Gdzie jestem" jest wyliczane, nie zapisywane: pierwszy pusty checkbox to następny krok. Dzięki temu cykl można przerwać, wyczyścić kontekst i wznowić jedną komendą - stan nigdy nie ginie.

Po zieleni automatów: potwierdzenie manualne od człowieka → staging wyłącznie plików dotkniętych w etapie (nigdy git add -A; brudne pliki spoza zestawu dostają osobne pytanie) → zatwierdzenie komunikatu → commit → SHA wpisany z powrotem do Progress.

Po każdym etapie decyzja: kontynuować w tym samym kontekście czy wyczyścić i wznowić komendą skopiowaną do schowka (/10x-implement <change-id> phase N). Ten mechanizm pozwala prowadzić kilka cykli równolegle - każdy tor ma własny kontekst i własny stan w swoim planie.

Przy rozjeździe planu z rzeczywistością zatrzymuje się i pyta: dostosować, pominąć czy wrócić do planowania. Na torze, który ma pracować bez nadzoru, użyj /10x-goal-implement - tam te decyzje podejmuje spisana polityka.