Czego nie widać w diffie

Załóżmy, że zmieniasz sposób sprawdzania dostępności produktu w aplikacji. Strona produktu uwzględnia już nową regułę, ale kod składania zamówienia nadal korzysta ze starej. W diffie wszystko wygląda dobrze, bo tego drugiego fragmentu kodu nikt nie zmienił.

Chcę, żeby agent AI szukał takich pominiętych miejsc, zanim uzna zadanie za skończone.

Przeglądając diff, widzisz wprowadzone zmiany. Nie zobaczysz w nim pliku, o którym agent zapomniał. Dlatego znalezienie wszystkich powiązanych miejsc w kodzie powinno być częścią zadania.

Zapisuję to w skillach, czyli instrukcjach dla agenta. Określam w nich, gdzie ma szukać i co ma mi pokazać, żebym mógł ocenić jego pracę. Porządkuję te instrukcje tak, żeby móc używać ich w kolejnych projektach.

Zanim zacznie zmieniać kod, agent powinien przeczytać CLAUDE.md lub AGENTS.md i sprawdzić, jak podobne rzeczy są już zrobione w projekcie. Od tego jest reuse-first. Potrzebny jest też krótki plan: co ma się zmienić w działaniu aplikacji i jak sprawdzimy, czy nie popełniliśmy błędu.

Po zmianie kodu agent korzysta z completeness. Szuka innych miejsc, które odczytują tę samą wartość lub podejmują tę samą decyzję. W przykładzie z dostępnością produktu musi zajrzeć również do kodu składania zamówienia. Przy każdym znalezionym miejscu powinien wskazać, czy je zmienił, czy zostawił bez zmian. W tym drugim przypadku powinien wyjaśnić dlaczego.

Samo potwierdzenie przyjęcia zamówienia nie mówi jeszcze, czy aplikacja prawidłowo zarezerwowała towar. Na etapie verify agent ma sprawdzić, jak zmiana faktycznie działa. Może uruchomić test konkretnego przypadku, wysłać rzeczywiste żądanie albo wykonać zapytanie i sprawdzić zapisane dane. Zależy mi na możliwie prostym sprawdzeniu, które mogłoby ujawnić błąd.

Po weryfikacji chcę jeszcze osobnego code review, jeśli zmiana dotyczy uwierzytelniania, pieniędzy, izolacji danych klientów, współbieżności lub ryzyka utraty danych. W Codex CLI lokalne zmiany sprawdza polecenie codex review --uncommitted. W aplikacji jest też /review, a w Claude Code można użyć /code-review do przeglądu lokalnego diffu. Te narzędzia można uruchomić jeszcze przed otwarciem pull requesta. Więcej o ich działaniu: code review w Codex i code review w Claude Code.

Każdą uwagę z review trzeba sprawdzić w kodzie. Jeśli faktycznie wskazuje błąd, po poprawce trzeba ponownie wykonać completeness i verify. Brak uwag w review nie zastępuje wcześniejszej weryfikacji.

Jak używać tych skilli

W repozytorium ze skillami znajdziesz reuse-first, completeness i verify w osobnych wersjach dla Claude Code i Codex. Obie opisują tę samą kolejność pracy, ale uwzględniają różnice w instrukcjach projektu i poleceniach służących do przeglądu kodu. Skopiuj całe foldery z claude/ do .claude/skills/ w swoim projekcie albo z codex/ do .agents/skills/. Polecenia instalacji dla obu wersji znajdziesz w README.

Poproś agenta, żeby przed zmianą kodu użył reuse-first, a po niej wykonał completeness i verify. Zapisz tę kolejność w CLAUDE.md lub AGENTS.md projektu. Określ też, przy jakich zmianach ma zrobić osobne code review. Zainstalowane skille są dostępne dla agenta. W instrukcjach projektu wyjaśniasz, kiedy i w jakiej kolejności ma ich używać. Do przeglądu kodu służą polecenia dostępne w danym narzędziu.

Na koniec chcę wiedzieć, które miejsca w kodzie agent sprawdził, jak zachowywał się zmieniony kod i które założenia nadal trzeba zweryfikować. Wtedy mogę zdecydować, czy przyjąć zmianę.