Automatyczne przeglądy kodu z Claude Code

Automatyczny przegląd kodu w Claude Code stawia przy każdym diffie drugiego, niezależnego czytelnika, zanim zobaczy go człowiek: /code-review w sesji, /security-review dla wrażliwych ścieżek, bramkę pre-push claude -p z ustrukturyzowanym werdyktem i claude ultrareview dla ryzykownych gałęzi. Gałąź z podłożonymi błędami dowodzi, że całość łapie istotne defekty.

Ta strona jest dla programistów, którzy chcą, żeby Claude wyłapał ich błędy, zanim zrobi to kolega z zespołu, oraz dla tech leadów, którzy odpowiadają za reguły przeglądu. Twoje sesje otwierają dziś więcej pull requestów, niż recenzenci są w stanie przeczytać. Komentarze ludzi się powtarzają: brakująca ścieżka błędu, niezwalidowane wejście, test pokrywający tylko happy path. Raport Faros AI z kwietnia 2026 r. (AI Engineering Report) zmierzył wzrost mediany czasu w przeglądzie o 441,5% w grupie 22 000 programistów. Mechaniczną część przeglądu warto oddać maszynie, żeby ludzie zachowali uwagę na decyzje wymagające osądu. Polecenia na tej stronie sprawdzono na Claude Code v2.1.283 z kanału latest.

Co daje ci automatyczny przegląd w Claude Code

• Stały rytuał /code-review dla każdej gałęzi, ze świadomie wybranym poziomem wysiłku i celem.
• Hook pre-push, który blokuje push tylko przy krytycznym defekcie wskazanym z nazwy pliku i numeru linii.
• Jeden zestaw reguł przeglądu w CLAUDE.md, który czytają przegląd lokalny, GitHub Action i zarządzany Code Review.
• Skill przeglądu dla zespołu, który działa w świeżym kontekście, więc recenzent nigdy nie dzieli rozumowania z autorem.
• Gałąź z podłożonymi błędami, która mierzy, co wyłapuje twój recenzent; uruchamiasz ją ponownie przy każdej zmianie reguł, modelu lub wersji Claude Code.

Które narzędzie przeglądu w Claude Code pasuje do którego momentu?

Najtańszą prywatną kontrolę uruchamiaj najpierw, żeby publiczny przegląd nadal był wart czytania.

Narzędzie	Kiedy działa	Co daje	Ograniczenia (sprawdzone 2026-09-26)
/code-review	W sesji, przed commitem	Błędy poprawności i propozycje porządków; --fix je nanosi, --comment publikuje w pull requeście	Czyta CLAUDE.md, nie czyta REVIEW.md
/security-review	Przed pull requestem, który dotyka uwierzytelniania, obsługi wejścia lub sekretów	Przegląd bezpieczeństwa diffa gałęzi	Tylko diff; audyt całego repozytorium opisuje strona audyty bezpieczeństwa z Claude Code
Bramka pre-push claude -p	Przy git push	Werdykt pass albo block, który twój skrypt czyta z JSON-a	git push --no-verify ją pomija, więc prawdziwą bramką pozostaje CI
claude ultrareview	Przed merge’em ryzykownej gałęzi	Flota agentów-recenzentów w chmurze; każde znalezisko jest niezależnie odtwarzane	Wymaga logowania kontem claude.ai; trzy jednorazowe darmowe uruchomienia na Pro i Max, potem „typically $5 to $25” w usage credits; niedostępne przy Zero Data Retention ani na Bedrock, Google Cloud i Foundry
Zarządzany Code Review	Na pull requestach: raz po otwarciu, po każdym pushu albo na @claude review, zależnie od wyzwalacza ustawionego dla repozytorium; działa na infrastrukturze Anthropic	Komentarze w linii z oceną Important, Nit lub Pre-existing; jego check run zawsze kończy się wynikiem neutralnym, więc sam nigdy nie blokuje merge’a	Team i Enterprise, research preview, „averages $15-25” za przegląd; niedostępny przy Zero Data Retention; konfigurację opisuje strona Claude Code w CI/CD

Ceny i dostępność to dane samego Anthropic z dokumentacji Code Review i Ultrareview.

Przejrzyj gałąź poleceniem /code-review

/code-review to wbudowany skill. /review jest teraz jego aliasem, a nie osobnym poleceniem. Bez argumentu przegląda commity twojej gałęzi, które wyprzedzają upstream, oraz niezacommitowane zmiany. Działa jako subagent w tle z własnym oknem kontekstu, więc możesz pracować dalej, gdy on czyta.

1. Uruchom przegląd z jawnie podanym poziomem wysiłku. W prompcie Claude Code:

   /code-review medium

   Na poziomach low i medium przegląd zgłasza tylko znaleziska, co do których ma największą pewność. Od high do max zakres się poszerza i przechodzą też znaleziska mniej pewne. Podawaj poziom za każdym razem: samo /code-review używa ostatnio wpisanego poziomu, nawet z wcześniejszej sesji.

2. Gdy trzeba, wskaż inny cel niż drzewo robocze. Cel podajesz po poziomie i flagach:

   /code-review high main...feature/billing-retry
   /code-review src/payments/
   /code-review 142

   Pierwsze polecenie przegląda zakres referencji, drugie ścieżkę, trzecie pull request 142.

3. Zrób commit, zanim użyjesz --fix. Przegląd w tle nanosi poprawki z --fix poza checkpointami sesji, więc /rewind ich nie cofnie. Z czystym commitem za sobą git diff pokazuje dokładnie, co zmieniła poprawka, a git restore . ją wycofuje.

   /code-review medium --fix

4. Opublikuj znaleziska tam, gdzie pracuje zespół. --comment umieszcza je w pull requeście na GitHubie jako komentarze w linii albo w merge requeście GitLaba jako jedną notatkę przez CLI glab:

   /code-review medium --comment 142

Prompt do skopiowania: zamień znaleziska z przeglądu w poprawki z testami

Take the findings from the last /code-review. For each finding rated as a bug:
1. Write a test that fails because of the bug. Run it and show me the failure.
2. Fix the code with the smallest change that makes the test pass.
3. Run the full test suite, typecheck and lint, and report each command with its exit code.
For each finding you think is wrong, do not change code: explain in one sentence why
it is a false positive and which file:line proves it.
End with a table: finding | test added | fixed / false positive.

Sednem tego promptu jest test, który najpierw nie przechodzi. Poprawka z testem, który zmienił się z czerwonego na zielony, to dowód do sprawdzenia w sekundę; poprawka bez testu to kolejny diff, który ktoś musi przeczytać.

Zapisz reguły przeglądu zespołu w jednym miejscu

Przegląd, który nie zna waszych konwencji, zgłasza nie to, co trzeba. Umieść reguły w jednym miejscu, które czyta każdy recenzent.

• CLAUDE.md czytają /code-review, GitHub Action i zarządzany Code Review. Zarządzany Code Review zgłasza nowe naruszenia tego pliku jako nity.
• REVIEW.md w katalogu głównym repozytorium czyta tylko zarządzany Code Review. Lokalny /code-review go ignoruje, więc regułę, która ma obowiązywać wszędzie, zapisz w CLAUDE.md.

Dodaj krótką sekcję przeglądu do projektowego CLAUDE.md:

## Review rules
- Blocking: missing authorization on a route under src/api/, SQL built from strings,
  an error swallowed in src/payments/, a migration that is not backward compatible,
  a test assertion removed or loosened.
- Do not flag: formatting, naming, import order (dprint and oxlint own those),
  anything under src/gen/, any lockfile.
- The `any` type under src/legacy/ is intentional. Do not flag it.
- Every finding cites file:line and names the test or command that demonstrates it.

Następnie daj zespołowi jedno polecenie przeglądu. Skill z context: fork działa jako osobny subagent, który startuje wyłącznie od treści skilla, bez rozmowy autora, a właśnie takiej niezależności oczekujesz od recenzenta. Zapisz to jako .claude/skills/pr-check/SKILL.md:

---
description: Independent pre-PR review of the current branch against origin/main. Use before opening a pull request.
disable-model-invocation: true
context: fork
allowed-tools: Read Grep Glob Bash(git diff *) Bash(git log *)
---

## Changes under review

!`git diff --stat origin/main...HEAD`

## Instructions

Review the diff between origin/main and HEAD. Read each changed file in full, not only
the hunks. Apply the "Review rules" section of CLAUDE.md. You never edit files.

Check, in this order: authorization and input validation, error handling at every
boundary, data and migration safety, and whether each changed behaviour has a test
that would fail without it.

Reply in exactly this shape:
VERDICT: APPROVE | REQUEST_CHANGES
FINDINGS:
- [blocker|major|minor] path:LINE: problem. Evidence: <test or command>
UNTESTED: <changed behaviour with no covering test, or "none">
CHECKED: <each command you ran>

allowed-tools z góry zatwierdza te narzędzia; nie odbiera pozostałych, więc „You never edit files” to polecenie, a nie ograniczenie. Recenzenta, który w ogóle nie może edytować plików, zbuduj jako subagenta z listą tools (zobacz własne subagenty).

Nie nazywaj go review: /review należy już do /code-review. disable-model-invocation: true sprawia, że uruchamia go tylko człowiek. Jeśli chcesz recenzenta, któremu Claude sam przekaże zadanie, z własną listą narzędzi i modelem, napisz subagenta; zobacz własne subagenty. Mechanikę skilli opisuje strona własne polecenia i skille.

Zablokuj push przy krytycznym znalezisku

Hook pre-push to ostatnia prywatna kontrola. Musi być szybki, może zawieść tylko na czymś, co potrafi nazwać, a o wyniku decyduje twój skrypt, nie proza modelu. Poniższy hook przekazuje diff do claude -p, pozwala tylko na narzędzia do czytania, ogranicza wydatek i czyta werdykt z structured_output, który waliduje --json-schema.

1. Zapisz hook jako .githooks/pre-push i nadaj mu prawo wykonania (chmod +x .githooks/pre-push). Hook wymaga jq w PATH; bez niego wypisuje ostrzeżenie i przepuszcza push:

   #!/usr/bin/env bash
   set -uo pipefail
   command -v jq >/dev/null || { echo "pre-push: jq missing; review skipped" >&2; exit 0; }
   
   base=$(git merge-base origin/main HEAD) || exit 0
   diff=$(git diff --no-color "$base"...HEAD)
   [ -z "$diff" ] && exit 0
   
   if [ "$(printf '%s' "$diff" | wc -l)" -gt 1500 ]; then
     echo "pre-push: diff over 1500 lines; run /code-review high before you push." >&2
     exit 0
   fi
   
   schema='{"type":"object","properties":{"verdict":{"enum":["pass","block"]},"findings":{"type":"array","items":{"type":"string"}}},"required":["verdict","findings"]}'
   
   if ! out=$(printf '%s' "$diff" | claude -p \
     "Review this diff for blocking defects only, as defined in the Review rules section of CLAUDE.md. Ignore style. Return verdict block only for a defect you can name by file and line; write each as 'file:line - problem - fix'." \
     --output-format json --json-schema "$schema" \
     --permission-mode dontAsk --allowedTools "Read" "Grep" "Glob" \
     --max-budget-usd 0.50); then
     echo "pre-push: Claude review did not complete; push allowed, CI still gates the merge." >&2
     exit 0
   fi
   
   if [ "$(jq -r '.structured_output.verdict // "missing"' <<< "$out")" = "block" ]; then
     echo "pre-push: blocked by Claude review:" >&2
     jq -r '.structured_output.findings[]' <<< "$out" >&2
     echo "Fix the findings, or push with --no-verify and say why in the pull request." >&2
     exit 1
   fi

2. Wskaż Gitowi śledzony katalog hooków, raz na każdy klon:

   git config core.hooksPath .githooks

3. Udowodnij, że hook blokuje. Na gałęzi roboczej dodaj trasę, która czyta identyfikator użytkownika z query stringa i zwraca rekord tego użytkownika bez sprawdzenia uprawnień, zrób commit i push. Hook musi wypisać znalezisko file:line i zakończyć się kodem 1. Jeśli przepuszcza, zaostrzaj Review rules, aż zacznie blokować.

Trzy decyzje w tym skrypcie są celowe. --permission-mode dontAsk odmawia każdego narzędzia, którego nie wymieniłeś, więc przegląd nie może edytować plików. Hook przepuszcza, gdy Claude nie zdoła skończyć (sieć, budżet, awaria), bo lokalny hook, który blokuje przy awarii, zostanie na stałe obchodzony przez --no-verify. Pomija też bardzo duże diffy, bo szybka kontrola 3000 linii to teatr; takie zmiany potrzebują /code-review high albo Ultrareview. Nie dodawaj --bare, żeby hook startował szybciej: tryb bare pomija CLAUDE.md, więc Review rules, na których opiera się prompt, w ogóle by się nie wczytały. Flagi trybu headless szczegółowo opisuje strona automatyzacja zadań w trybie headless.

Przejrzyj zmiany wrażliwe na bezpieczeństwo poleceniem /security-review

Gdy gałąź dotyka uwierzytelniania, obsługi sesji, parsowania wejścia, ścieżek plików lub sekretów, uruchom /security-review, zanim otworzysz pull request. Polecenie przegląda diff gałęzi pod kątem bezpieczeństwa. Jeśli chcesz kontroli działającej już podczas pisania kodu przez Claude’a, zainstaluj plugin security-guidance, który działa jako hooki. Wymaga Pythona 3.8 lub nowszego w PATH:

claude plugin install security-guidance@claude-plugins-official

Skanery, plugin Claude Security i testy exploitów jako dowód opisuje strona audyty bezpieczeństwa z Claude Code. Bramki bezpieczeństwa dla agentów innych dostawców porównuje strona bramki bezpieczeństwa agentów.

Prompt do skopiowania: przegląd bezpieczeństwa bieżącej gałęzi

Run a security review of the diff between origin/main and HEAD. Do not edit files.
Check each item and answer yes, no or not applicable, citing file:line:
1. Every new or changed route checks authorization, not only authentication.
2. Every user-controlled value is validated before it reaches a query, a shell
   command, a file path or an outbound URL.
3. Database queries are parameterized; HTML output is escaped.
4. Error responses and logs leak no tokens, emails, stack traces or request bodies.
5. No credential, key or token appears in code, tests or fixtures.
6. New dependencies: name each one and say why existing code or dependencies
   could not do the job.
For every "no", give severity (critical/high/medium/low), the CWE ID if one fits,
and the smallest fix. If everything passes, list what you checked.

Zdobądź drugą opinię dla ryzykownej gałęzi

Niektóre zmiany zasługują na więcej niż jednego czytelnika: płatności, uprawnienia, migracje danych, wszystko, czego nie da się łatwo wycofać. Dwie opcje sięgają głębiej niż /code-review.

Ultrareview uruchamia w chmurze flotę agentów-recenzentów i odtwarza każde znalezisko, zanim je zgłosi. Z powłoki:

claude ultrareview                 # current branch against the default branch
claude ultrareview 142             # pull request 142
claude ultrareview 142 --post      # also post the findings to the pull request as you
claude ultrareview --json > bugs.json

W sesji ten sam przegląd to /code-review ultra. Wymaga logowania kontem claude.ai (sesja z samym kluczem API musi najpierw wykonać /login) i zwykle trwa 5–10 minut. Przegląd gałęzi lub pull requesta obejmuje domyślnie do 500 zmienionych plików i 8000 zmienionych linii; większą zmianę podziel. Jeśli samo repozytorium jest zbyt duże, by je spakować do wysłania, wypchnij gałąź, otwórz szkic pull requesta i uruchom claude ultrareview <numer>. Samodzielne uruchomienie claude ultrareview jest też sposobem na zgodę na rozliczenie w usage credits; przebieg claude -p '/code-review ultra' zatrzymuje się przed startem, gdy przegląd miałby zużyć kredyty. Tam, gdzie Ultrareview jest niedostępny (Zero Data Retention, Bedrock, Google Cloud, Foundry), /code-review ultra wraca do przeglądu lokalnego.

Plugin pr-review-toolkit z marketplace’u Anthropic claude-plugins-official dodaje /pr-review-toolkit:review-pr i sześć wyspecjalizowanych subagentów, na przykład łowcę cichych błędów i analizator testów. Przekaż aspekty, żeby uruchomić tylko potrzebne:

claude plugin install pr-review-toolkit@claude-plugins-official --scope project

/pr-review-toolkit:review-pr tests errors

Kosztuje około 2000 tokenów stale obecnego kontekstu na sesję (zmierzone przez claude plugin details na Claude Code 2.1.283), więc instaluj go w zakresie projektu w repozytoriach, które go potrzebują, a nie globalnie. Uwaga: plugin o nazwie code-review z tego samego marketplace’u wywołuje się jako /code-review:code-review; samo /code-review zawsze uruchamia wbudowany skill.

Skąd wiesz, że recenzent łapie to, co ważne?

Przegląd, który niczego nie zgłasza, wygląda tak samo, czy kod jest czysty, czy recenzent jest ślepy. Mierz go tak, jak mierzysz zestaw testów: podłóż defekty i policz, co wróciło.

1. Trzymaj gałąź review-fixture z pięcioma podłożonymi defektami, po jednym z każdej klasy, na której ci zależy: brakujące sprawdzenie uprawnień, SQL sklejany ze stringów, błąd połknięty w ścieżce płatności, off-by-one w paginacji i asercja w teście poluzowana tak, że zawsze przechodzi. Listę podłożonych defektów trzymaj poza gałęzią: wynik recenzenta, który widzi klucz odpowiedzi, niczego nie mierzy.

2. Uruchom każdego recenzenta trzy razy na tej gałęzi — /code-review medium main...review-fixture, /pr-check oraz prompt z hooka pre-push przez claude -p. Modele nie są deterministyczne, więc jedno uruchomienie niewiele dowodzi.

3. Zapisz cztery liczby dla każdego recenzenta: wyłapane podłożone defekty (na pięć), znaleziska spoza podłożonych, które są błędne (fałszywe alarmy), czas zegarowy oraz total_cost_usd z wyjścia JSON.

4. Uruchamiaj tę gałąź ponownie przy każdej zmianie Review rules, modelu, poziomu wysiłku lub wersji Claude Code. Spadek skuteczności to regresja, tak samo jak nieprzechodzący test.

Prompt do skopiowania: zbuduj gałąź z podłożonymi błędami

Create a branch named review-fixture from main. Do not push it.
Plant exactly five defects in realistic places in this codebase, one of each:
1. A route that returns another user's data because it skips the authorization check.
2. A database query built by string concatenation from request input.
3. A caught error in payment or billing code that is logged and then ignored.
4. An off-by-one in a pagination or date-range boundary.
5. A test whose key assertion is loosened so it passes for wrong output.
Make each change look like ordinary work, with no comments that hint at the defect.
Commit each defect separately, with commit messages that do not name the defect.
Then write the answer key to ../review-fixture-key.md, outside the repository, listing
each defect as file:line and its class. Do not commit the key or add it to the branch:
a reviewer reads the whole checkout, and a key on the branch hands it the answers.

Kto za co odpowiada:

Dowód	Właściciel
Skuteczność i odsetek fałszywych alarmów na gałęzi testowej, mierzone po każdej zmianie	Tech lead, który odpowiada za Review rules
Werdykt pass z bramki pre-push i czysty /code-review	Autor zmiany
Testy, typy i lint zielone w CI, poza kontrolą Claude’a	CI
Akceptacja ścieżek z CODEOWNERS: migracje, uwierzytelnianie, pieniądze, testy, konfiguracja CI, CLAUDE.md	Wskazany właściciel kodu

Zarządzany Code Review sam nie powoduje niepowodzenia żadnej kontroli: jego check run Claude Code Review zawsze kończy się wynikiem neutralnym. Jeśli znaleziska Important mają blokować merge, odczytaj liczniki ważności z tego check runa we własnym jobie CI i zakończ job błędem, gdy normal (liczba znalezisk Important) jest większe od zera:

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'

Polecenie wypisuje liczniki w rodzaju {"normal": 2, "nit": 1, "pre_existing": 0} (format z dokumentacji Code Review Anthropic, sprawdzone 2026-09-26). Włączenie zarządzanego Code Review opisuje strona Claude Code w CI/CD.

Automatyczny przegląd to czujnik, a nie akceptacja. Co człowiek czyta zamiast całego diffa, opisuje strona code review pull requesta agenta bez czytania każdej linii, a co musi zawierać pull request — pakiet dowodów.

Gdy automatyczny przegląd kodu zawodzi

Objaw	Przyczyna	Co zrobić
Zespół przestaje czytać znaleziska Claude’a	Uwagi o stylu i mało pewne znaleziska zagłuszają prawdziwe	Uruchamiaj /code-review na poziomie medium i wypisz kategorie „Do not flag” w CLAUDE.md
Znalezisk nagle jest dużo więcej albo dużo mniej	Samo /code-review użyło poziomu wpisanego we wcześniejszej sesji	Zawsze podawaj poziom; zapisz go w skillu zespołu lub w hooku
/rewind nie cofnął poprawek z przeglądu	Edycje z --fix w tle są poza checkpointami	Rób commit przed --fix; wycofuj przez git restore albo git revert
Reguła z REVIEW.md jest ignorowana lokalnie	Lokalny /code-review nie czyta REVIEW.md	Przenieś reguły, które mają obowiązywać wszędzie, do CLAUDE.md
Bramka pre-push przepuszcza gałąź, którą powinna zatrzymać	Prompt nie pytał o tę klasę defektu	Dopisz klasę do Review rules i powtarzaj test na gałęzi review-fixture, aż zostanie wyłapana
Push wisi albo pada podczas awarii API	Hook czeka na sieć	Zostaw gałąź, która przepuszcza przy błędzie; blokującą bramką pozostaje CI
Recenzent akceptuje kod napisany w tej samej sesji	Recenzent i autor dzielą kontekst	Użyj /pr-check z context: fork, świeżej sesji albo claude ultrareview
Pull request osłabia własny przegląd	Gałąź edytuje CLAUDE.md, .claude/ albo .githooks/	Obejmij te ścieżki CODEOWNERS; zmiany reguł przeglądaj jak kod
/code-review:code-review i /code-review dają różne wyniki	To różni recenzenci: plugin z marketplace’u i wbudowany skill	Wybierz jednego na każdy etap i zapisz to w zasadach zespołu dla kontrybutorów
Ultrareview się nie uruchamia	Zero Data Retention, dostawca chmury bez Ultrareview, logowanie samym kluczem API albo -p zatrzymane na zgodę na rozliczenie	Zaloguj się kontem claude.ai przez /login, uruchom claude ultrareview samodzielnie albo wróć do lokalnego /code-review high
Ultrareview odrzuca diff jako zbyt duży	Gałąź lub pull request przekracza domyślny limit 500 plików lub 8000 linii	Podziel zmianę na mniejsze pull requesty
Ultrareview zamiast przeglądu gałęzi proponuje tryb PR	Repozytorium jest zbyt duże, by je spakować do wysłania	Wypchnij gałąź, otwórz szkic pull requesta i przejrzyj go po numerze: claude ultrareview <numer>
Zarządzany Code Review znalazł błąd, a pull request i tak został zmerge’owany	Jego check run jest zawsze neutralny i niczego nie blokuje	Niech własny job CI kończy się błędem, gdy licznik normal w check runie jest większy od zera

Co dalej z automatyzacją przeglądów

• Warunek wstępny: bramka jest tak mocna jak jej wyrocznia, więc zacznij od testowania i debugowania z Claude Code.
• Ten sam przegląd na każdym pull requeście: Claude Code w CI/CD.
• Pilnuj kolejki, gdy większość pull requestów otwierają agenci: kolejka code review.
• Dlaczego dowody zastępują czytanie linia po linii: czytanie dowodów zamiast kodu.
• Inne skille i pluginy do przeglądu kodu w porównaniu: code review wewnątrz agenta.
• Cały etap wdrażania dla tego narzędzia: przegląd i wdrożenie z Claude Code.

Korzystasz też z innego agenta? To samo zadanie opisują strony code review z Codex i code review z Cursorem.