Agent team do code review projektu
Jak i kiedy użyć
Użyj tego prompta w Claude Code, OpenAI Codex albo innym agentowym środowisku codingowym, które ma dostęp do plików projektu i potrafi czytać repozytorium. Najlepiej sprawdza się przed większym mergem, deployem, refaktorem albo po zakończeniu feature. Wklej zakres review, stack, najważniejsze ryzyka i informację, czy review ma być tylko czytające, czy może proponować poprawki. Przed uruchomieniem ustal, czy agent ma tylko raportować ryzyka, czy może od razu przygotować poprawki. Przy pracy na produkcyjnym kodzie zacznij od trybu read only i wymagaj file level references.
Prompt
Stwórz zespół AI reviewerów do code review mojego projektu. Pracuj w trybie ostrożnym: najpierw czytaj, potem diagnozuj, a dopiero po zgodzie proponuj zmiany. Kontekst projektu: [opisz produkt, stack, backend, frontend, bazę danych, autoryzację, hosting, integracje i środowiska] Zakres review: [foldery, moduły, pull request, diff albo feature] Ryzyka szczególne: [bezpieczeństwo, płatności, dane osobowe, wydajność, deploy, koszty] Stwórz 4 role: 1. Security reviewer: szuka injection, auth bypass, data leaks, złych uprawnień, sekretów, problemów OWASP, braku walidacji i ryzyk w integracjach. 2. Performance reviewer: szuka wolnych zapytań, N plus 1, dużych payloadów, braku cache, niepotrzebnych requestów, cold startów i kosztownych operacji. 3. Reliability reviewer: szuka brakującego error handlingu, braku retry, race conditions, problemów z timeoutami, braku idempotency i niespójności danych. 4. Product risk reviewer: sprawdza, czy kod realizuje właściwy user flow, czy edge casey są obsłużone i czy zmiana nie psuje doświadczenia użytkownika. Każdy finding zapisz w formacie: severity, obszar, plik albo moduł, opis problemu, dowód, sposób odtworzenia, rekomendowana poprawka, ryzyko poprawki i test, który powinien istnieć. Na końcu przygotuj: 1. Listę CRITICAL i HIGH do naprawy przed mergem. 2. Listę MEDIUM i LOW do backlogu. 3. Pytania do właściciela. 4. Decyzję: merge, merge po poprawkach, albo blokada. Format końcowy: executive summary, tabela CRITICAL i HIGH, tabela MEDIUM i LOW, testy do dodania, decyzje architektoniczne, pytania do właściciela, rekomendacja merge. Każdy reviewer ma pracować niezależnie, a potem wskazać konflikty między swoimi rekomendacjami. Jeżeli nie masz dostępu do plików, poproś o diff albo strukturę projektu. Nie zmyślaj luk bezpieczeństwa bez dowodu. Jeśli widzisz tylko hipotezę, oznacz ją jako hipotezę i napisz, jak ją sprawdzić. Review ma priorytetyzować realne ryzyka produkcyjne.
Najczęstsze pytania
Kiedy używać agent team do code review?
Najlepiej przed większym mergem, deployem, refaktorem albo po zakończeniu funkcji. Prompt pomaga wymusić review z kilku perspektyw, zamiast jednej ogólnej opinii o kodzie.
Czy prompt wymaga dostępu do repozytorium?
Najlepiej działa w narzędziu z dostępem do repozytorium, takim jak Codex albo Claude Code. Bez dostępu do plików można użyć go jako szablonu, ale trzeba wkleić diff, pliki albo opis architektury.
Jakie role są w tym review?
Prompt uruchamia role bezpieczeństwa, wydajności, niezawodności i ryzyka produktowego. Dzięki temu review nie skupia się wyłącznie na składni albo stylu kodu.
Jak powinny wyglądać findings w review?
Każdy finding powinien mieć severity, obszar, dowód, sposób odtworzenia, rekomendowaną poprawkę i test. Bez tego review jest trudne do wykonania i łatwo zmienia się w ogólne uwagi.
Czy agent powinien od razu poprawiać kod?
Nie zawsze. Przy dużym review najpierw powinien czytać i raportować. Poprawki warto robić po decyzji właściciela, szczególnie gdy mogą zmienić architekturę, bezpieczeństwo albo zachowanie produktu.