SKILL · review

Protokół Code Review

Ustrukturyzowana metodologia code review, która wykracza poza „wygląda ok." Tworzy listę ustaleń rankingowaną według ważności, obejmującą poprawność, bezpieczeństwo, wydajność, utrzymywalność i design. Każde ustalenie zawiera problem, dlaczego ma znaczenie i konkretną sugestię naprawy. Łapie to, co lintery omijają — błędy logiczne, dryft architektoniczny, ukryte sprzężenia i pominięte przypadki brzegowe.

Requires

Claude

code-reviewjakośćnajlepsze-praktykipull-requestdevelopment

Zainstaluj jako skill Claude Code

Umieść w ~/.claude/skills/<nazwa>/SKILL.md

.skill

Protokół Code Review

Co robi ten skill

Przeprowadza ustrukturyzowane, zdecydowane code review, które łapie to, czego zautomatyzowane narzędzia nie widzą. Wynikiem jest lista ustaleń rankingowana według ważności — każde z opisem problemu, wpływem i konkretną naprawą.

To nie jest przejście lintera. Łapie:

Błędy logiczne i pominięte przypadki brzegowe
Luki bezpieczeństwa (injection, obejście auth, wyciek danych)
Pułapki wydajnościowe (zapytania N+1, niepotrzebne re-rendery, wycieki pamięci)
Dryft architektoniczny (wzorce niespójne z codebase)
Ukryte sprzężenia i naruszenia abstrakcji
Luki w obsłudze błędów (połknięte błędy, brakująca walidacja)
Warunki wyścigu i problemy współbieżności

Poziomy ważności

Poziom	Znaczenie	Wymagane działanie
KRYTYCZNY	Luka bezpieczeństwa, ryzyko utraty danych lub crash	Musi być naprawiony przed merge
WYSOKI	Bug, regresja wydajności lub naruszenie designu	Powinien być naprawiony przed merge
ŚREDNI	Problem utrzymywalności, pominięty edge case lub code smell	Napraw teraz lub stwórz ticket
NISKI	Styl, nazewnictwo, drobna poprawa	Fajnie by było
NOTATKA	Obserwacja, pytanie lub sugestia do dyskusji	Brak wymaganego działania

Checklist review

1. Poprawność

Czy kod robi to, co deklaruje?
Czy wszystkie przypadki brzegowe są obsłużone? (null, puste, wartości graniczne, stany błędu)
Czy są błędy off-by-one?
Czy logika biznesowa jest poprawna?

2. Bezpieczeństwo

Czy dane wejściowe są walidowane i sanityzowane?
Czy są wektory SQL/NoSQL injection?
Czy autentykacja/autoryzacja jest sprawdzona?
Czy sekrety są zahardkodowane?
Czy wrażliwe dane są eksponowane w logach, błędach lub odpowiedziach?

3. Wydajność

Czy są wzorce zapytań N+1?
Niepotrzebne obliczenia w pętlach lub renderach?
Brakująca paginacja dla nieograniczonych zapytań?
Wycieki pamięci (niezamknięte połączenia, rosnące kolekcje)?
Brakujące cache'owanie tam, gdzie by pomogło?

4. Obsługa błędów

Czy błędy są łapane i obsługiwane odpowiednio?
Czy komunikaty błędów ujawniają szczegóły implementacji?
Czy jest fallback/retry dla przejściowych awarii?
Czy błędy async są prawidłowo propagowane?

5. Design i architektura

Czy zmiana podąża za istniejącymi wzorcami w codebase?
Czy jest niepotrzebne sprzężenie między modułami?
Czy odpowiedzialności są wyraźnie rozdzielone?
Czy to mogłoby być prostsze?

6. Testowanie

Czy są testy dla nowego/zmienionego kodu?
Czy testy pokrywają happy path I edge case'y?
Czy mocki są realistyczne?
Czy niepowodzenie testu wskazałoby na rzeczywisty problem?

7. Czytelność

Czy nazwy są opisowe i spójne?
Czy kod jest samodokumentujący, czy potrzebuje komentarzy?
Czy funkcje są wystarczająco małe, żeby zrozumieć na pierwszy rzut oka?
Czy jest martwy kod lub zakomentowany kod?

Format wyjścia

## Code Review: {opis}

### Podsumowanie
{1-2 zdania — przegląd zmiany i ogólna ocena}

### Ustalenia

#### KRYTYCZNY: {tytuł}
**Plik:** `ścieżka/do/pliku.ts:42`
**Problem:** {co jest nie tak}
**Wpływ:** {dlaczego to ma znaczenie}
**Naprawa:** {konkretna sugestia z kodem}

#### WYSOKI: {tytuł}
...

Proces

Zrozum intencję — przeczytaj opis PR, powiązane issue lub zapytaj, co zmiana robi
Czytaj diff holistycznie — zrozum całą zmianę przed komentowaniem szczegółów
Zastosuj checklistę — systematyczne przejście przez każdą kategorię
Rankinguj ustalenia — ważność determinuje wymagane działanie
Sugeruj naprawy — każde ustalenie zawiera konkretną naprawę, nie tylko „to jest źle"
Doceń dobrą robotę — wskaż też dobrze napisany kod

Antywzorce

Czepianie się stylu, gdy są prawdziwe bugi do złapania
„Wygląda ok" bez faktycznego czytania kodu
Przepisywanie kodu autora w swoim preferowanym stylu
Blokowanie na ustaleniach NISKI
Recenzowanie tylko diffa bez zrozumienia kontekstu