Automatyczne przeglądy kodu z Claude Code

Automatyczny przegląd kodu w Claude Code stawia niezależnych czytelników przy każdej zmianie, zanim zobaczy ją człowiek: /code-review w sesji, bramkę pre-push claude -p, zarządzany Code Review na każdym pull requeście i claude ultrareview dla ryzykownych gałęzi. Zespół Claude Code w Anthropic opisał 2026-10-15, że łączy taki przegląd z kontrolami bezpieczeństwa, CI i akceptacją człowieka skalowaną ryzykiem.

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. Fakty o produkcie sprawdzono 2026-10-16 na code.claude.com, a flagi CLI na Claude Code 2.1.302.

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 czyta każdy recenzent, oraz REVIEW.md dla przeglądu zarządzanego.
• Zarządzany Code Review z poziomem ustawionym osobno dla każdego repozytorium i bramką scalania, która blokuje merge przy znaleziskach Important i nierozwiązanych wątkach.
• Gałąź z podłożonymi błędami, która mierzy, co wyłapuje twój recenzent, oraz limity rund, które chronią przed pętlą między agentem-autorem a agentem-recenzentem.

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-10-16)
/code-review	W sesji, przed commitem	Błędy poprawności oraz, zależnie od modelu i poziomu wysiłku, propozycje porządków; --fix je nanosi, --comment publikuje je w pull requeście na GitHubie albo w merge requeście GitLaba	Każdy plan; 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	Research preview; logowanie kontem claude.ai; trzy jednorazowe darmowe uruchomienia na Pro i Max, potem „typically $5 to $25” w usage credits; gdzie jest niedostępny
Zarządzany Code Review	Na pull requestach, zależnie od ustawienia repozytorium; działa na infrastrukturze Anthropic	Komentarze przy liniach z oceną Important, Nit lub Pre-existing, podsumowanie i neutralny check run	Plany Team i Enterprise, tylko GitHub; bez stałej ceny za przegląd; dostępność i koszty

Dostępność, limity i rozliczenia to dane samego Anthropic ze stron Code Review, kosztów Code Review, lokalnego przeglądu i Ultrareview.

Jak zespół Claude Code układa warstwy przeglądu kodu?

Zespół Claude Code w Anthropic opisał 2026-10-15 w tekście How the Claude Code team does code review (claude.dev Blog; liczby podaje sam Anthropic o własnych repozytoriach, to nie benchmark branżowy), że układa wokół zmiany siedem warstw: sprawdzenie, które agent potrafi uruchomić, i przegląd subagenta w świeżym kontekście jeszcze przed pull requestem, Code Review na każdym pull requeście, przegląd bezpieczeństwa, który potrafi zablokować, wymagane CI, akceptację człowieka skalowaną ryzykiem, kolejkę scalania z flagami i wydaniem, które trafia na kanał latest przed stable, oraz szybkie wycofanie. Celem jest scalanie większości pull requestów z co najwyżej jednym człowiekiem w pętli, którym może być autor, bez wzrostu liczby cofnięć i incydentów; bezpiecznikiem są wskaźniki cofnięć i incydentów. Ta strona buduje pierwsze trzy warstwy. Warstwy i dowody, które czyta człowiek, opisuje code review PR-a agenta bez czytania każdej linii, a poziomy ryzyka governance i autonomia.

Przejrzyj gałąź poleceniem /code-review

/code-review to wbudowany skill działający w każdym planie; przegląd odbywa się w twojej sesji, więc liczy się do zużycia planu albo do rozliczenia API. /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 poziomie low przegląd zgłasza znaleziska, co do których ma największą pewność, więc widzisz mniej fałszywych alarmów; od medium do max zakres się poszerza. Od v2.1.290 poziom medium na modelach bez dostrojonych ustawień przeglądu, w tym Opus 5.5 i Sonnet 5.5, zgłasza też znaleziska dotyczące porządkowania kodu i konwencji z CLAUDE.md. Podawaj poziom za każdym razem: samo /code-review używa ostatnio wpisanego poziomu od low do max, nawet z wcześniejszej sesji (v2.1.223 lub nowsza), chyba że wpisano go w przebiegu -p. Obie bramki wersji działają na obu kanałach wydań (stable 2.1.292, latest 2.1.302; npm dist-tags, 2026-10-16).

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 poza checkpointami sesji, a /rewind przywraca tylko pliki, które Claude zdążył już edytować w twojej rozmowie. Resztę cofniesz gitem: git diff pokazuje zmiany, git restore . cofa śledzone pliki, a git clean -n wypisuje nowe pliki do usunięcia. Przegląd uruchomiony na pierwszym planie (-p albo CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1) edytuje w trakcie twojej tury, więc /rewind działa wtedy jak zwykle.

   /code-review medium --fix

4. Opublikuj znaleziska tam, gdzie pracuje zespół. --comment umieszcza je w pull requeście na GitHubie jako komentarze przy liniach albo w merge requeście GitLaba jako jedną notatkę przez CLI glab (v2.1.257 lub nowsza; podaj merge request jako jego URL albo !123):

   /code-review medium --comment 142

5. Zmień liczbę zgłaszanych znalezisk, gdy zwykły limit nie pasuje do diffu. --max-findings <n> zgłasza najwyżej n znalezisk, a --max-findings all wszystkie, zamiast zwykłego limitu (v2.1.288 lub nowsza, oba kanały). Kolejne przeglądy używają tej wartości, dopóki nie podasz --max-findings default; wartość z przebiegu -p nie jest zapamiętywana:

   /code-review high --max-findings all main...feature/billing-retry

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 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ę, a poprawka bez testu to kolejny diff do przeczytania.

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, który zgłasza zmianę łamiącą jego zasady z wagą odpowiednią do problemu. Zespół Claude Code w Anthropic opisał 2026-10-15, że trzyma ten plik krótki i odsyła z niego do innych dokumentów, bo każdy przegląd go wczytuje.
• REVIEW.md w katalogu głównym repozytorium czyta tylko zarządzany Code Review, więc regułę, która ma obowiązywać wszędzie, zapisz w CLAUDE.md. Co powinno się w nim znaleźć, opisuje sekcja jak napisać REVIEW.md, którego recenzent się trzyma.

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, albo takiego, któremu Claude sam przekaże zadanie, napisz jako subagenta z listą tools (zobacz własne subagenty). Nie nazywaj skilla review: /review należy już do /code-review. disable-model-invocation: true sprawia, że uruchamia go tylko człowiek. 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 są celowe. --permission-mode dontAsk odmawia każdego wywołania narzędzia, które wymagałoby pytania, 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 startował szybciej: tryb bare pomija CLAUDE.md, więc Review rules w ogóle by się nie wczytały. Flagi headless: 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

Zespół Claude Code w Anthropic opisał 2026-10-15, że nie scala pull requesta, dopóki jakiekolwiek znalezisko z przeglądu błędów lub bezpieczeństwa jest otwarte: naprawiasz je (późniejszy commit, który naprawia problem, zamyka je sam) albo zamykasz wątek krótkim uzasadnieniem. Tekst mówi, że to samo można ustawić przez otwartoźródłową GitHub Action do przeglądu bezpieczeństwa albo /security-review; bramkę buduje sekcja jak sprawić, żeby znalezisko bezpieczeństwa blokowało merge.

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. Jego strona oznacza go jako research preview (sprawdzone 2026-10-16), więc cena i dostępność mogą się zmienić. 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 15–25 minut. Przegląd gałęzi przyjmuje domyślnie do 500 zmienionych plików i 8000 zmienionych linii (strona zastrzega, że wartości mogą się zmienić); jeśli repozytorium jest zbyt duże, by je spakować, 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, konfiguracja HIPAA, Bedrock, Google Cloud, Foundry), /code-review ultra wraca do przeglądu lokalnego; organizacja z kluczami szyfrującymi zarządzanymi przez klienta w ogóle go nie uruchomi i przegląda lokalnie przez /code-review.

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.

Jak uruchomić zarządzany Code Review na każdym pull requeście?

Zarządzany Code Review przegląda pull requesty w tych repozytoriach GitHuba, dla których włączył go Owner twojej organizacji Claude. Kilku agentów czyta każdą zmianę, krok weryfikacji odsiewa fałszywe alarmy, a znaleziska trafiają do pull requesta jako komentarze przy liniach z etykietą Important, Nit albo Pre-existing (błąd, którego ten pull request nie wprowadził), podsumowanie i check run Claude Code Review. Przegląd działa na infrastrukturze Anthropic i nie buduje ani nie uruchamia twojego kodu (Code Review, sprawdzone 2026-10-16). Aktualna strona nie ma etykiety research preview, a tekst Anthropic z 2026-10-15 nazywa go „generally available on Team and Enterprise plans”; komunikat o premierze z 2026-03-09 nadal mówi o research preview, więc ufaj stronie i tekstowi.

Wymaga planu Team lub Enterprise i GitHuba (także GitHub Enterprise Server i GitHub Enterprise Cloud z data residency) oraz organizacji Claude w tych planach, nawet gdy twoi programiści korzystają z Bedrocka, Google Cloud Agent Platform albo Microsoft Foundry. Jest niedostępny przy Zero Data Retention i konfiguracji HIPAA, nie obejmuje go Business Associate Agreement (BAA) i nie działa jeszcze z kluczami szyfrującymi zarządzanymi przez klienta (CMEK). Owner włącza go w Admin settings > Claude Code (Set up Code Review; stronę CI opisuje Claude Code w CI/CD).

Jaki poziom przeglądu wybrać dla którego repozytorium?

Owner ustawia jeden poziom dla organizacji i może go zmienić dla pojedynczego repozytorium; nie ma wyboru modelu, a nowy poziom obowiązuje późniejsze przeglądy. Quick to lżejszy przebieg, najszybszy i najtańszy; Standard, domyślny, równoważy głębokość, szybkość i koszt; Deep jest najdokładniejszy, najwolniejszy i najdroższy. Zespół Claude Code w Anthropic opisał 2026-10-15, że jego administratorzy ustawiają każde repozytorium na jeden z trzech poziomów, a „Deep is worth it where one missed bug costs more than the extra review time”. Quick wybierz dla rutynowego kodu, a Deep dla płatności, autoryzacji, migracji i wszystkiego, co trudno wycofać.

Kiedy mają się uruchamiać przeglądy?

Każde repozytorium ma ustawienie Review runs. Once after PR creation przegląda pull request, gdy zostaje otwarty, ponownie otwarty albo oznaczony jako gotowy. After every push przegląda każdy push, więc koszt mnoży się przez liczbę pushy; od tego ustawienia zaczyna repozytorium dodane z panelu administratora, chyba że jego organizacja GitHub jest objęta jako całość. Manual przegląda tylko wtedy, gdy ktoś o to poprosi komentarzem. Każdy z prawem zapisu może rozpocząć przegląd nowym komentarzem najwyższego poziomu, który zaczyna się od @claude review; @claude review always przegląda też każdy kolejny push. Automatyczne przeglądy pomijają szkice i pull requesty z forków, a komenda w komentarzu działa na obu. Późniejszy przegląd automatyczny skupia się na tym, co zmieniło się od poprzedniego, publikuje mniej nitów i znalezisk typu pre-existing, a w podsumowaniu podaje, ile pominął; @claude review obejmuje cały pull request jeszcze raz.

Jak zablokować merge z powodu znaleziska?

Przegląd nigdy nie zatwierdza ani nie blokuje pull requesta. Check run kończy się wynikiem neutralnym, a gdy automatyczny przegląd się nie uruchomił, bo push nie zmienił plików, wynikiem pominiętym. Nigdy nie kończy się porażką, więc zakończony przegląd nie oblewa wymaganej kontroli, a pull request możesz scalić bez odpowiedzi na znalezisko, chyba że wymagają jej reguły repozytorium. Dwa mechanizmy sprawiają, że znaleziska blokują:

1. Wymagaj rozwiązania każdego wątku. Włącz Require conversation resolution before merging w regule ochrony gałęzi (GitHub: about protected branches).

2. Niech job CI kończy się błędem według liczników ważności. Ostatnia linia tekstu Details check runa to komentarz czytelny dla maszyn z liczbą znalezisk w każdej wadze; normal zlicza znaleziska Important, także wcześniejsze, których wątki nadal są otwarte. Ten skrypt czeka na przegląd i kończy się błędem, gdy normal jest większe od zera:

   #!/usr/bin/env bash
   # usage: code-review-gate.sh OWNER/REPO HEAD_SHA [WAIT_SECONDS] [POLL_SECONDS]
   set -euo pipefail
   repo="$1"; sha="$2"; wait_max="${3:-900}"; poll="${4:-15}"
   url="repos/$repo/commits/$sha/check-runs?check_name=Claude%20Code%20Review"
   run=""
   for ((waited = 0; waited <= wait_max; waited += poll)); do
     run=$(gh api "$url" --jq '.check_runs | max_by(.id) // empty | "\(.id) \(.status) \(.conclusion)"') \
       || { echo "gate: cannot list check runs: blocking" >&2; exit 1; }
     case "$run" in *" completed "*) break ;; esac
     sleep "$poll"
   done
   case "$run" in *" completed "*) ;; *) echo "gate: no finished Claude Code Review run on $sha after ${wait_max}s: blocking" >&2; exit 1 ;; esac
   case "$run" in *" skipped") echo "gate: review skipped because the push changed no files" >&2; exit 0 ;; esac
   out=$(gh api "repos/$repo/check-runs/${run%% *}" --jq '.output') \
     || { echo "gate: cannot read the check run: blocking" >&2; exit 1; }
   [ "$(jq -r '.title' <<< "$out")" = "Code review found no issues" ] && exit 0
   counts=$(jq -r '.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson' <<< "$out" 2>/dev/null) \
     || { echo "gate: no severity line in the check run: no verdict, blocking" >&2; exit 1; }
   echo "severity counts: $counts"
   [ "$(jq -r '.normal // 0' <<< "$counts")" -eq 0 ] || { echo "gate: Important findings are open" >&2; exit 1; }

   Skrypt blokuje przy przekroczeniu czasu, przy błędzie API i przy braku linii z licznikami (przegląd, który zawiódł, przekroczył limit czasu, został anulowany albo zastąpiony nowszym, jej nie zostawia, a brak werdyktu to nie zero znalezisk). Przegląd pominięty oznacza, że push nie zmienił plików, więc skrypt go przepuszcza; wcześniejsze znaleziska nadal liczy pierwszy mechanizm. Potrzebuje przeglądu każdego nowego commita, więc używaj go tylko w repozytoriach ustawionych na After every push; przy dwóch pozostałych ustawieniach nowy commit nie dostaje przeglądu, więc tam polegaj na pierwszym mechanizmie. Anthropic opisuje to samo parsowanie w Read and request reviews on a pull request.

Ile kosztuje zarządzany Code Review?

Code Review nie ma stałej ceny za przegląd (sprawdzone 2026-10-16). Rozlicza się według zużycia tokenów przez usage credits, a płaci organizacja; koszt rośnie z poziomem przeglądu, rozmiarem zmiany, otaczającym kodem i liczbą znalezisk do zweryfikowania. W pilotażu ustaw miesięczny limit wydatków na claude.ai/admin-settings/usage, włącz Code Review w kilku repozytoriach na Once after PR creation albo Manual, a potem pomnóż Average cost każdego repozytorium (Admin settings > Claude Code) przez liczbę jego pull requestów w miesiącu, a dla After every push jeszcze przez liczbę pushy na pull request. Przegląd jest pomijany, z komentarzem wskazującym przyczynę, gdy skończy się limit wydatków, limit organizacji albo saldo usage credits. Komunikat o premierze z 2026-03-09 podawał, że przeglądy „generally average $15–25”, a obecna strona o kosztach tego nie powtarza, więc opieraj się na własnej średniej.

Jak napisać REVIEW.md, którego recenzent się trzyma?

REVIEW.md w katalogu głównym repozytorium dostraja zarządzany Code Review; plik w podkatalogu dodaje kontrole dla tej ścieżki. Przegląd czyta go z gałęzi bazowej pull requesta albo z gałęzi domyślnej, nigdy ze zmian samego pull requesta, więc najpierw scal zmianę. Chroń gałąź domyślną: instrukcje, które obniżają wagę, wyłączają ścieżki albo ograniczają nity, działają tylko wtedy, gdy plik z katalogu głównego jest czytany z chronionej gałęzi domyślnej. Przy niechronionej gałęzi domyślnej przegląd czyta tylko plik z katalogu głównego i check run to zaznacza; gdy nie potrafi potwierdzić ochrony, nie czyta żadnego (Customize Code Review, sprawdzone 2026-10-16).

Zespół Claude Code w Anthropic opisał 2026-10-15, że dobre pliki REVIEW.md jego właścicieli kodu są krótkie, mówią, jak wygląda porażka w tym repozytorium („for docs it’s ‘it lies,’ for config it’s ‘it misroutes’”), ograniczają liczbę nitów, wymieniają ścieżki do pominięcia, żądają pliku i linii jako dowodu zamiast domysłu na podstawie nazwy oraz proszą o podsumowanie, które zaczyna się od liczby i mówi wprost, gdy nie ma nic do poprawienia. Zespół sprawdza też osobno, czy recenzent trzyma się pliku. Przykład zbudowany z tych cech:

# Review instructions

## What failure looks like here

- Docs: a page that lies. A command, flag or default the code lacks is Important.
- Config: a value that misroutes. A secret in a file is Important.
- src/payments/: an unscoped query or a swallowed error is Important.
- Style and naming are Nit at most.

## Cap the nits

At most five Nits per review.

## Do not report

- Anything CI enforces (lint, formatting, types), src/gen/ and lockfiles

## Evidence

Cite file:line for every claim about behaviour; never infer it from a name.

## Summary

Start with a count, for example "2 Important, 3 Nit". If nothing needs fixing, say so and stop.

Strona Anthropic mówi, że REVIEW.md zmienia to, co przegląd znajduje i zgłasza, a nie jego format, więc potraktuj regułę o podsumowaniu jako prośbę i przeczytaj kilka prawdziwych podsumowań, zanim na niej polegasz.

Naprawiaj powtarzające się znaleziska u źródła. Zespół naprawia przyczynę w skillu, regułą lintera albo w plikach z instrukcjami, a strona Anthropic radzi poprosić maintainera o dopisanie reguły do REVIEW.md. Nasze przyporządkowanie: formatowanie i błędy typów trafiają do formattera, lintera lub hooka (potem wpisz kategorię w „Do not report”); konwencja, której powinna przestrzegać każda sesja, do CLAUDE.md; waga, limity nitów i pliki generowane do REVIEW.md; wieloetapowa kontrola do skilla przeglądu zespołu. Gdy przegląd coś przegapi, zespół pyta, czego modelowi zabrakło przed oczami, i wpisuje poprawkę do CLAUDE.md, skilla albo nowej kontroli.

Jak odpowiedzieć na każde znalezisko Code Review?

Zespół Claude Code w Anthropic opisał 2026-10-15, że na każde znalezisko trzeba odpowiedzieć: albo je naprawiasz, albo rozwiązujesz wątek z uzasadnieniem, a często agent podejmuje poprawkę w nocy. Jego lista wdrożeniowa każe „require every review thread resolved before merge”, ale nie wskazuje ustawienia; w publicznym produkcie udokumentowanym mechanizmem jest ochrona gałęzi wymagająca rozwiązania rozmów (zob. jak zablokować merge z powodu znaleziska). Jak odpowiadać (sprawdzone 2026-10-16):

• Napraw: wypchnij zmianę; następny przegląd rozwiąże wątek, gdy uzna problem za naprawiony.
• Odrzuć fałszywy alarm: napisz uzasadnienie w wątku, potem rozwiąż go na GitHubie. Sama odpowiedź nie zamyka znaleziska.
• Wyjaśnij lub zgłoś sprzeciw: odpowiedz. Odpowiedź nie uruchamia przeglądu; następny ją przeczyta i może rozwiązać wątek albo dodać jedną odpowiedź uzupełniającą.
• Zdobądź przegląd bez pushu: skomentuj @claude review.

Prompt do skopiowania: odpowiedz na każdy wątek Code Review w pull requeście

List the review threads on pull request PR_NUMBER with `gh api graphql`:
repository(owner: OWNER, name: REPO) { pullRequest(number: PR_NUMBER) {
reviewThreads(first: 100) { nodes { id isResolved path line comments(first: 20) {
nodes { body author { login } } } } } } }. For every thread where isResolved is
false, do one thing. FIX it: failing test, smallest fix, full suite, push, reply
with the commit hash. Or, if the finding is wrong or intended, reply with one
sentence that cites file:line, then resolve the thread with the resolveReviewThread
mutation. After three review rounds, stop and list the findings that keep
returning. End with a table: thread | fix or reason | evidence.

Zastąp PR_NUMBER, OWNER i REPO swoimi wartościami. Tekst mówi, że człowiek odpowiada za każdą wydaną zmianę, bez względu na to, kto ją napisał, więc niech osoba kierująca agentem sprawdzi każde uzasadnienie.

Jak zapobiec pętli między agentem-autorem a agentem-recenzentem?

Agent-autor i agent-recenzent mogą dawać sobie nawzajem pracę bez końca. Zespół Claude Code w Anthropic opisał 2026-10-15, że jeden pull request do CLI przeszedł w nocy ponad pięćdziesiąt rund przeglądu i poprawek, a około 59% tego, co recenzent wciąż zgłaszał, dotyczyło kodu obecnego od jego pierwszego przebiegu. Szum kosztuje więcej przy autorze-agencie, który naprawia każdego nita, a to oznacza kolejny commit i kolejną rundę. Zespół zmienił ponowny przegląd na cztery sposoby (porównanie z publicznym produktem: 2026-10-16):

• Limit rund: po trzech rundach recenzent prosi autora, żeby cofnął się o krok i przemyślał podejście. Strony Code Review nie wymieniają takiego ustawienia, więc użyj bloku CLAUDE.md z tej sekcji i ustaw Once after PR creation albo Manual.
• Ponowny przegląd tylko diffa po kilku pierwszych przebiegach. Najbliższe wbudowane zachowanie to późniejszy przegląd automatyczny skupiony na zmianach (Anthropic nie mówi, czy to ten sam mechanizm).
• Wskazywanie klasy błędu, żeby autor naprawił każde wystąpienie: każ agentowi-autorowi przeszukać repozytorium pod kątem klasy i dopisz ją do REVIEW.md.
• Bez powtórzeń opublikowanych znalezisk. Strony nie opisują filtra powtórzeń; ponowny przegląd czyta odpowiedzi i może dodać jedną odpowiedź uzupełniającą.

Dla swoich wewnętrznych pull requestów zespół podaje (dane własne), że odsetek przechodzących po jednej rundzie przeglądu i poprawek wzrósł z 65% do 78%, odsetek potrzebujących pięciu lub więcej rund spadł z 8,9% do 1,5%, a średnia liczba przeglądów do przejścia z 2,08 do 1,32. Śledzi liczbę rund do przejścia obok skuteczności wykrywania (recall). Nasza adaptacja dla CLAUDE.md twoich agentów-autorów:

## Review rounds

- Answer every review finding: fix it, or resolve the thread with one sentence that
  cites file:line. Never re-fix a finding you already answered.
- When a finding is one instance of a class of bug, fix every instance in one commit.
- After three rounds on one pull request, stop, list the findings that keep returning
  and ask the human whether to change the approach.

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.

5. Dodawaj do tej gałęzi każdy incydent. Zespół Claude Code w Anthropic opisał 2026-10-15, że z dawnych pull requestów, które spowodowały incydenty (z ich poprawkami naprzód i cofnięciami), zrobił eval: każdy błąd potwierdzili inżynierowie znający kod, recenzent uruchamia się na tym zbiorze codziennie, a każda zmiana recenzenta jest oceniana na całości. Zespół sortuje też każdy komentarz recenzenta według reakcji autora (naprawił, uznał za błędny, uznał za zamierzony albo za bez znaczenia) i uruchamia recenzenta na pull requestach, o których wie, że są czyste. Zacznij od mniejszej skali: dodaj pull request, który stoi za każdym cofnięciem lub incydentem, i przez miesiąc licz reakcje autorów.

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 hint comments, and commit each one
separately with a message that does not name the defect. Write the answer key
(file:line and class of each defect) to ../review-fixture-key.md, outside the
repository, and never commit it: a reviewer reads the whole checkout.

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
Każdy wątek Claude Code Review naprawiony albo zamknięty z uzasadnieniem	Ochrona gałęzi, która wymaga rozwiązania wszystkich rozmów
Wskaźniki cofnięć i incydentów, czyli bezpiecznik pokazujący, że czas człowieka został zaoszczędzony, a nie przesunięty	Tech lead, co miesiąc, obok liczby rund przeglądu na pull request

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	Na co dzień uruchamiaj /code-review low (zostawia znaleziska, co do których ma największą pewność), a medium i wyżej na ryzykowne scalenia; kategorie „Do not flag” wypisz w CLAUDE.md, a nity ogranicz w REVIEW.md
Znalezisk nagle jest dużo więcej albo dużo mniej	Samo /code-review użyło poziomu wpisanego we wcześniejszej sesji	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 ., usuń nowe pliki po git clean -n albo użyj 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
/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
Ultrareview się nie uruchamia	Zero Data Retention, konfiguracja HIPAA, CMEK, 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 użyj lokalnego /code-review high
Ultrareview odrzuca diff jako zbyt duży	Przekroczony domyślny limit 500 plików lub 8000 linii	Podziel zmianę na mniejsze pull requesty
Ultrareview proponuje tryb PR	Repozytorium jest zbyt duże, by je spakować do wysłania	Wypchnij gałąź, otwórz szkic pull requesta i uruchom claude ultrareview <numer>
Zarządzany Code Review znalazł błąd, a pull request i tak został scalony	Jego check run jest neutralny, a ochrona gałęzi nie wymagała rozwiązanych wątków	Wymagaj rozwiązania rozmów albo niech job CI kończy się błędem przy normal (jak zablokować merge)
Zmiana w REVIEW.md nie działa na własny pull request	Plik jest czytany tylko z gałęzi bazowej lub domyślnej; przy niechronionej gałęzi domyślnej przegląd czyta tylko plik z katalogu głównego, a reguły obniżające wagę, pomijające ścieżki lub ograniczające nity działają tylko z chronionej	Najpierw scal zmianę i chroń gałąź domyślną klasyczną regułą albo ruleset
Na pull requeście nie ruszył żaden przegląd	Repozytorium ma ustawienie Manual, pull request jest szkicem albo pochodzi z forka, albo wyczerpał się limit budżetu	Skomentuj @claude review (potrzebujesz prawa zapisu); po komentarzu „Code review skipped” administrator najpierw podnosi limit na claude.ai/admin-settings/usage
Znalezisko dostało odpowiedź, a nadal blokuje merge	Sama odpowiedź nie zamyka znaleziska	Rozwiąż wątek albo wypchnij poprawkę
Rundy przeglądu się nie kończą	Agent-autor naprawia każde znalezisko, a agent-recenzent w każdej rundzie znajduje kilka kolejnych	Wpisz limit rund i regułę o klasie błędu do CLAUDE.md autora oraz użyj Once after PR creation albo Manual
Wydatki na przeglądy są wyższe niż planowano	After every push mnoży koszt przez liczbę pushy	Przenieś ruchliwe repozytoria na Once after PR creation albo Manual i sprawdź każdy Average cost

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; żeby znaleziska bezpieczeństwa blokowały merge, zob. audyty bezpieczeństwa z Claude Code.
• 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, człowiek w pętli i governance i autonomia.
• Inne narzędzia i boty: code review wewnątrz agenta, boty do code review z AI, code review z Codex i code review z Cursorem. Cały etap: przegląd i wdrożenie z Claude Code.