Agent zarabia dopiero, gdy działa bez Ciebie

Zanim zespół zbuduje narzędzie z rozpędu, luka trafia na papier: PRD definiuje problem, użytkowników i granice - i dopiero na tym zapada decyzja, czy w ogóle budować.

Wejście: shape-notes.md z etapu odkrywania (albo surowe notatki). Wyjście: context/foundation/prd.md zgodny z zamkniętym schematem - 10 sekcji dla projektu od zera, 11 dla zmiany w istniejącym systemie.

Heurystyka 0-4 ocenia, czy notatki są ukształtowane: blok checkpoint, wymagania w formacie FR-NNN, scenariusze Given / When / Then, jawna reguła biznesowa. Poniżej progu skill ostrzega wprost: czego brakuje i z jaką konsekwencją dla dokumentu. Generacja w pamięci i walidacja ze schematem przed zapisem na dysk.

Dla zmiany w istniejącym systemie: przegląd obecnego stanu, problem i motywacja, persony, kryteria sukcesu z guardrails „co nie może się zepsuć", historyjki, wymagania funkcjonalne i niefunkcjonalne, Non-Goals oraz Open Questions.

Skill jest generatorem dokumentu, nie facylitatorem odkrywania: nigdy nie wymyśla decyzji domenowych, reguł biznesowych ani kryteriów sukcesu. Każda luka trafia dosłownie do Open Questions - rozstrzyga ją człowiek, nie generator.

Recenzja na każdym PR bez człowieka w pętli: agent w CI porównuje diff z planem, który PR deklaruje realizować, i zostawia trwały ślad audytowy - raport, komentarze inline, werdykt.

Wejście: PR plus plan - znaleziony konwencją context/changes/<id>/plan.md albo linią „Plan:" w opisie PR. Wyjście: raport reviews/impl-review.md commitowany na branch PR, komentarze inline na zmienionych liniach i komentarz-podsumowanie z tabelą wymiarów.

Diff od merge-base → trzy subagenty równolegle: dryf względem planu (MATCH / DRIFT / MISSING / EXTRA), bezpieczeństwo i zgodność ze wzorcami sąsiadów, pokrycie testami → komendy weryfikacji z planu → oceny siedmiu wymiarów → werdykt APPROVED / NEEDS ATTENTION / REJECTED.

Severity (CRITICAL / WARNING / OBSERVATION), impact, wymiar, lokalizacja plik:linia, detal i propozycja poprawki z jawną siłą, kosztem i pewnością. Limit 10 znalezisk - powiązane problemy konsolidowane, sortowanie po severity oddziela znaleziska warte poprawki od szumu.

Skill niczego nie pyta i nie edytuje kodu: czyta, analizuje, raportuje. Brak planu w PR to neutralny komentarz i wyjście, nie porażka. Werdykt REJECTED blokuje check dopiero w workflow - z etykietą-obejściem po ludzkiej decyzji.

Zarejestrować nazwę lub schemat, które są nośne: ich zmiana wymusza skoordynowaną aktualizację u konsumentów. Rejestr sprawia, że przyszłe review planów automatycznie flaguje zmiany łamiące kontrakt.

Wejście: świeżo utworzony albo rozpoznany kontrakt - pole schematu, endpoint API, format frontmattera. Wyjście: wpis H2 w docs/reference/contract-surfaces.md, po którym /10x-plan-review grepuje tekst każdego przyszłego planu.

Nazwa powierzchni (nagłówek H2 to dosłowny cel grep - pełna kwalifikacja zamiast gołego identyfikatora), kanoniczna definicja plik:linia, właściciele i konsumenci, checklist zmian łamiących gotowy do wklejenia w plan migracji.

Cztery pytania wywiadu - treść pisze użytkownik, skill niczego nie podpowiada z góry → echo wpisu i potwierdzenie → self-bootstrap pliku przy pierwszym użyciu → append na końcu rejestru.

Plik jest append-only - rewizje robi człowiek ręcznie i to celowe tarcie. Jeden wpis na wywołanie. Poprzeczka wejścia: jeśli zmiana nazwy psuje coś tylko w lokalnym module, to nie jest kontrakt i wpis nie powstaje.

Wykonać zatwierdzony plan bez człowieka przy klawiaturze: autonomiczny odpowiednik /10x-implement dla sesji /goal i uruchomień headless. Zaufanie zastępują jawne polityki, nie dobra wola agenta.

Warunek celu spisany przed startem: zakres plików, zakaz osłabiania testów, limit tur. Polityka braku interakcji - nikt nie patrzy, więc każda decyzja ma z góry ustaloną regułę, a wątpliwości rozstrzyga interpretacja konserwatywna: mniej plików, mniej zmian zachowania, bliżej litery planu.

Implementację każdego etapu pisze delegowany subagent, ale bramki jakości biegną w głównym kontekście: kryteria planu → deliberate-break check (test musi zaczerwienić się na celowo zepsutym kodzie - inaczej niczego nie chroni) → pełny zestaw testów → commit wyłącznie na zielono, osobno per etap.

Rozjazd planu z rzeczywistością jest klasyfikowany: Minor (przeniesiony plik, zmieniona nazwa) - adaptowany i raportowany jedną linią; Structural (brakująca zależność, inna architektura) - blok STOP z instrukcją wznowienia. W razie wątpliwości: Structural.

Ewaluator celu czyta wyłącznie transkrypt: każdy werdykt bramki, SHA commita i adaptacja muszą zostać opowiedziane w odpowiedzi - bramka, która przeszła po cichu, nie istnieje. Maksymalnie 2 próby naprawy na bramkę, potem STOP; kroki manualne wracają do człowieka jako zamykająca checklista.