Code review PR-a agenta bez czytania każdej linii

Code review pull requesta agenta bez czytania każdej linii to sześciokrokowa ocena: sprawdzenie zmiany specyfikacji, potwierdzenie dowodów, przegląd flag ryzyka, lektura każdej zmiany wyroczni, próbka kilku hotspotów, a na końcu akceptacja, zwrot albo eskalacja. Agent recenzujący najpierw przechodzi mechaniczną checklistę, a wskazany człowiek czyta kod tylko w klasach eskalacji.

Wtorek rano, czeka na ciebie dziewięć pull requestów agentów. Pierwszy ma 640 linii w 14 plikach, wszystkie sprawdzenia są zielone, a opis brzmi „Zaimplementowano paginację zgodnie z prośbą”. Możesz spędzić nad nim cały ranek albo przejrzeć go pobieżnie i liczyć na szczęście. Ta strona daje trzecią drogę: około 15 minut na pull request i ślad, którego możesz bronić.

Co zyskujesz dzięki ocenie PR-ów agenta

• Sześciokrokowy protokół oceny z budżetem czasu i warunkiem zatrzymania dla każdego kroku.
• Checklistę dla agenta recenzującego, którą commitujesz do repozytorium: dawną 50-punktową checklistę dla człowieka, przepisaną na sprawdzenia, które agent wykonuje i dokumentuje dowodami.
• Listę eskalacji do człowieka: klasy zmian, w których ktoś wciąż czyta kod, i pytanie, na które ta osoba odpowiada.
• Trzy werdykty (akceptacja, zwrot, eskalacja) z kryteriami, dzięki którym dwóch recenzentów dochodzi do tej samej decyzji.
• Trzy prompty do skopiowania i konfigurację dla Claude Code, Codeksa i Cursora.
• Cztery miary, które pokazują, czy sama ocena działa.

Ta strona wprowadza w praktykę czytanie dowodów zamiast kodu; zacznij od tamtej strony, jeśli zatwierdzanie nieprzeczytanego kodu to dla ciebie wciąż nowy pomysł.

Dlaczego 50-punktowa checklista dla człowieka przestała działać

Dawną odpowiedzią była 50-punktowa checklista stosowana przez człowieka czytającego diff. Punkty były trafne; problemem był czytelnik.

Pull requesty jednocześnie urosły i dłużej czekają na review. DX zmierzył, że mediana rozmiaru pull requesta wzrosła z 44 do 72 linii między lipcem 2025 a czerwcem 2026 (DX, Justin Reock, 17 czerwca 2026). Raport Acceleration Whiplash firmy Faros AI (kwiecień 2026, telemetria z 22 000 programistów) pokazał wzrost mediany czasu w review o 441,5% i o 31,3% więcej pull requestów scalanych bez żadnego review. Checklista zależna od czytania każdej linii kończy się na dwa sposoby: kolejka staje albo czytanie po cichu zanika.

Rozwiązanie zachowuje każdy punkt i przenosi go gdzie indziej: agent wykonuje mechaniczne sprawdzenia i dołącza dowody, a człowiek czyta raport, zmiany wyroczni i krótką próbkę kodu, a potem decyduje. To przejście z poziomu 3, na którym przeglądasz diffy, na poziom 4, na którym piszesz specyfikacje i oceniasz dowody.

Jak działa sześciokrokowa ocena?

Wykonuj kroki po kolei. Każdy może wcześniej zakończyć review, więc drogie kroki wykonujesz tylko na pull requestach, które przeszły tanie.

Krok	Pytanie	Na co patrzysz	Budżet	Kończy review, gdy
1. Zmiana specyfikacji	Czy agent zmienił to, o co prosiliśmy, i tylko to?	Ticket i lista zmian zachowania prostym językiem	2 min	Zmiana zachowania, o którą nikt nie prosił, albo brak specyfikacji → zwrot
2. Dowody	Czy każde kryterium akceptacji ma sprawdzenie wykonane na tym commicie?	Mapowanie kryteriów, wyniki testów, zrzuty ekranu lub trace’y z działania	3 min	Kryterium oznaczone UNVERIFIED albo wyniki ze starszego commita → zwrot
3. Flagi ryzyka	Czy zmiana dotyka klasy eskalacji albo czy agent recenzujący zgłosił bloker?	Raport agenta recenzującego i lista zmienionych ścieżek	1 min	Klasa eskalacji → eskalacja; znalezisko P0 lub P1 → zwrot
4. Zmiany wyroczni	Czy zmiana zmieniła znaczenie „zielonego”?	Diff testów, fixture’ów, snapshotów, CI, lintera i konfiguracji typów	3 min	Sprawdzenie poluzowane bez uzasadnienia w specyfikacji → zwrot
5. Próbka hotspotów	Czy kod, którego nie czytałem, ukrywa coś, czego nie wychwyciły dowody?	Do trzech fragmentów diffa, wybranych według reguły, zanim na nie spojrzysz	5 min	Realny problem → zwrot i dopisanie brakującego sprawdzenia
6. Decyzja	Akceptacja, zwrot czy eskalacja?	Twoje notatki z kroków 1–5	1 min	—

Budżet 15 minut to nasza wyjściowa zasada, nie wynik badań. Jeśli pull requesta nie da się ocenić w tym czasie, to też jest informacja: jest za duży, ma słabe dowody albo należy do klasy eskalacji.

1. Porównaj zmianę specyfikacji z ticketem. Pull request mówi w zdaniach, które zachowanie się zmieniło: „GET /orders zwraca 50 pozycji na stronę i next_cursor; stary parametr page zwraca 400”. Porównaj to z tym, o co prosił ticket. Rozrost zakresu, źle zrozumiane wymaganie i cicha zmiana kontraktu wychodzą tu bez otwierania pliku. Jeśli agent nie potrafi w kilku zdaniach wyjaśnić architektury, którą zmienił, zwróć pull request.

2. Potwierdź dowody, linia po linii. Każde kryterium akceptacji potrzebuje jednej linii: kryterium, sprawdzenie, które je dowodzi, i wynik, na przykład old page param returns 400 → orders.contract.test.ts:88 → pass. Upewnij się, że wyniki dotyczą ostatniego commita, a nie wcześniejszego pusha. Przy zmianach wizualnych lub operacyjnych szukaj zrzutu ekranu albo trace’a dla każdej ścieżki akceptacji, łącznie z nazwanymi przypadkami błędów. Format tego manifestu jest zdefiniowany w jednym miejscu: w pakiecie dowodów.

3. Przejrzyj flagi ryzyka. Raport agenta recenzującego wymienia dotknięte klasy eskalacji i znaleziska według wagi. Klasa eskalacji kieruje pull request do wskazanej osoby, która czyta kod; znalezisko P0 lub P1 odsyła go agentowi-autorowi.

4. Przeczytaj w całości każdą zmianę wyroczni. To jedyna część diffa, którą czytasz zawsze. Zmiana testu, fixture’a, snapshotu, kroku CI, reguły lintera albo tsconfig zmienia znaczenie każdego innego sprawdzenia: asercja poluzowana z dokładnej wartości do „truthy”, pominięty test albo wygenerowany od nowa snapshot mogą przepuścić błędną implementację. Jeśli testy są nowe, zapytaj, czy nie przeszłyby po usunięciu funkcji; mechaniczną odpowiedź, testy mutacyjne, opisuje strona o tym, jak silna jest twoja wyrocznia.

5. Przeczytaj próbkę hotspotów wybraną, zanim spojrzysz na kod. Wybierz do trzech fragmentów diffa. Pierwsze dwa wybierasz według reguły, w tej kolejności: fragment, który agent recenzujący oznaczył poniżej swojego progu pewności; obsługa błędów wokół wywołań zewnętrznych, ponowień i timeoutów; współbieżność albo przejścia stanów; nowa zależność albo nowa abstrakcja; fragment, którego nie wyjaśnia żadne zdanie zmiany specyfikacji; największy fragment poza testami. Trzeci wybierasz losowo (losowy zmieniony plik, a w nim największy fragment), żeby nic w samym pull requeście nie decydowało o tym, co zostanie przeczytane. Te fragmenty czytasz porządnie.

6. Zdecyduj i zapisz werdykt w pull requeście. Skorzystaj z tabeli werdyktów poniżej i zapisz, które fragmenty przeczytałeś, żeby ślad zaufania pokazywał, co człowiek czytał.

Losowy plik wybieraj poleceniem, a nie na oko, a potem przeczytaj jego największy fragment:

# Terminal, na gałęzi pull requesta
git diff --name-only main...HEAD -- . ':!*.test.*' ':!*.spec.*' ':!**/__snapshots__/**' | sort -R | head -n 1

Akceptacja, zwrot czy eskalacja: który werdykt pasuje?

Zapisz werdykt i jego uzasadnienie w komentarzu do pull requesta; „LGTM” nie jest uzasadnieniem.

Werdykt	Kryteria (wszystkie muszą być spełnione)	Kto działa dalej
Akceptacja	Zmiana specyfikacji zgadza się z ticketem; każde kryterium ma zaliczone sprawdzenie na ostatnim commicie; żadna zmiana wyroczni nie luzuje sprawdzenia; żadna klasa eskalacji nie jest dotknięta; próbka nie wywołała pytania, na które nie odpowiadają dowody	Ty scalasz albo rusza auto-merge; produkcję pilnuje progressive delivery
Zwrot	Którekolwiek z: zmiana zachowania, o którą nikt nie prosił, kryterium UNVERIFIED, nieaktualne wyniki, poluzowane sprawdzenie, znalezisko P0 lub P1, problem w przeczytanym fragmencie albo pull request ponad budżet rozmiaru zespołu	Agent-autor, z niespełnionymi punktami jako następnym promptem. Maksymalnie dwie rundy, potem przejmuje człowiek
Eskalacja	Którekolwiek z: dotknięta klasa eskalacji; agent recenzujący i dowody się nie zgadzają; agent nie mógł wykonać sprawdzenia, na które się powołuje; zmiana podejmuje decyzję projektową, której specyfikacja nie rozstrzygnęła	Wskazana osoba czytająca kod w tej klasie, przez CODEOWNERS

Limit dwóch zwrotów pochodzi z praktyki. W Stripe agenci Minions mają limit najwyżej dwóch rund CI („at most two rounds of CI”) i tworzą ponad 1300 scalanych co tydzień pull requestów (blog inżynierski Stripe, Alistair Gray, Minions części 1 i 2, 9 i 19 lutego 2026). To dane wewnętrzne jednej firmy, nie benchmark. Pull request, który po dwóch zwrotach wciąż nie przechodzi, ma problem ze specyfikacją, a nie z kodem. Ograniczona pętla review i poprawek pokazuje, jak zautomatyzować ścieżkę zwrotu z tym warunkiem zatrzymania.

Gdy przeczytany fragment ujawni realny problem, napisz też sprawdzenie, które by go wychwyciło, żeby następny pull request z tą samą wadą nie przeszedł, zanim ktokolwiek zajrzy do próbki.

Checklista dla agenta recenzującego

Poniższa checklista to dawna 50-punktowa checklista dla człowieka, zachowana punkt po punkcie i przepisana tak, że każdy punkt wymaga od agenta dowodu (polecenia i jego kodu wyjścia, file:line, wyniku wyszukiwania), a nie opinii. Zacommituj ją jako .github/review/agent-checklist.md i ustaw tech leada jako jej code ownera, żeby standard review zmieniał się tylko przez pull request, który przeszedł review. Checklista zostaje po angielsku, bo to prompt.

.github/review/agent-checklist.md

# Review-agent checklist

Review the changes on this branch against main. Do not edit any file.
Run checks; never infer their results. Report only what could matter in
production. No style comments unless the style hides a bug.

Mark every item PASS, FAIL or N/A with one line of evidence: a command and its
exit status, a file:line, or a search result. For every FAIL give severity
(P0 blocks merge, P1 fix before merge, P2 fix soon, P3 optional), file:line,
why it matters in production, and the smallest safe fix.

## 1. Scope and intent
- Link the ticket or spec. If there is none, FAIL and stop.
- List every behaviour change as a sentence. Flag any the ticket did not ask for.
- List files the change did not need, and any refactor mixed into feature work.
- List what the change intentionally does not do, and every assumption made.
- Explain in three sentences the architecture this change touches. If you cannot, FAIL.
- Check names, copy, comments and examples against the product's domain terms.

## 2. Context fit
- For each new piece, name the existing local pattern it follows (file:line).
  FAIL a new architecture where a local pattern exists.
- Search for an existing utility, type, hook, component or service this duplicates.
- For each new abstraction, show the current call sites it deduplicates.
- Check public interfaces stay backward-compatible unless the PR declares a break.
- Check naming, error handling, logging, telemetry and analytics against the
  surrounding module and its existing helpers.
- Check module boundaries and the CODEOWNERS owner of every touched path.

## 3. Correctness
- Per changed function, list which of these a test covers: empty input,
  null/undefined, limits, duplicates, timeouts. Name the missing ones.
- For each external call, state what happens on partial failure.
- Find un-awaited async work, and fire-and-forget work without lifecycle handling.
- Check state transitions are explicit and cannot skip a required step.
- Check date, currency, locale and timezone logic is deterministic.
- Check retries, idempotency and duplicate events wherever messages, webhooks or
  payments are handled.
- Compare output shapes with the existing API contracts and types.
- Say whether tests use realistic data or only toy fixtures.

## 4. Tests (the oracle)
- List every changed test, fixture, snapshot, CI, lint and type-config file,
  each marked stricter, looser or neutral.
- For each new test, name the bug it catches. FAIL a test that passes with the
  feature removed.
- Confirm at least one failure-path test per changed behaviour.
- Flag mocks inside the logic under test instead of at system boundaries.
- Flag regenerated snapshots, sleeps, fixed waits and live network calls.
- Run the project's test, type-check and lint commands. Paste each command and
  its exit status, and the commit SHA they ran on.

## 5. Security and privacy
- Validate every new input at the boundary.
- Check authorization separately from authentication on every new route or action.
- Trace every user-controlled value into SQL, shell, file paths, HTML and URLs.
- Check no secret is logged, returned, committed or shipped in the client bundle.
- List any widened permission, OAuth scope, CORS, CSP or webhook trust, with its reason.
- Check sensitive data is redacted in logs, analytics and error messages.
- Check uploads, redirects and callbacks are limited to expected origins and types.
- For every new dependency, confirm it exists on the registry under the intended
  name and is maintained.

## 6. Data and migrations
- Check schema changes stay compatible during a rolling deploy.
- Check migrations are idempotent or ship a rollback, and preserve existing data.
- Check new queries use an index or a bounded scan where volume matters.
- Check jobs and webhooks tolerate duplicate delivery.
- Check deletes are soft, recoverable, or justified in the PR description.

## 7. Performance and operations
- Flag unbounded loops, N+1 queries and repeated network calls.
- Check expensive work is cached, batched, queued or paginated.
- Report client bundle growth from new imports, if the build reports sizes.
- Check errors carry enough context to debug without private data.
- Check new critical paths have monitoring, alerting or analytics.
- Check security-sensitive paths fail closed and UX paths fail gracefully.

## 8. Reviewability
- Report changed lines excluding generated files. FAIL above 400 lines.
- Flag formatting-only churn and generated code that was not simplified.
- Flag comments that restate the code instead of explaining a decision.
- Check screenshots or traces are attached for visual or operational changes.
- Name the single riskiest hunk and why, in two sentences.

## 9. Escalation classes
List every touched path in these classes: auth, permissions, tenancy, admin;
billing, payments, refunds, pricing; schema and migrations; public API, SDK and
webhook contracts; privacy, deletion, export, consent; rate limits, abuse
prevention, security headers; tests, CI, lint and type config.

## Output, in this order
1. Findings, P0 first.
2. Checklist results: PASS, FAIL or N/A with evidence, per item.
3. Escalation classes touched, with paths.
4. Suggested verdict: APPROVE, RETURN or ESCALATE, and the reason.

Budżet 400 linii w sekcji 8 to wartość wyjściowa; ustaw go na budżet rozmiaru, który zespół uzgodnił w kolejce code review. Proponowany werdykt jest tylko propozycją: agent recenzujący nigdy nie akceptuje ani nie scala zmian.

Które zmiany wciąż czyta człowiek?

Sekcja 9 checklisty wskazuje te klasy. W każdej wskazana osoba czyta też kod, bo wyrocznia jest słaba, informacja zwrotna przychodzi powoli albo szkodę trudno odwrócić.

Klasa eskalacji	Dlaczego dowody nie wystarczą	Pytanie, na które odpowiada czytający kod
Uwierzytelnianie, autoryzacja, uprawnienia, tenancy, funkcje administracyjne	Testy dowodzą dozwolonych ścieżek; błąd kryje się w ścieżce, której nikt nie przetestował	Czy jakikolwiek wywołujący dotrze do danych lub akcji, do których nie powinien?
Pieniądze: rozliczenia, płatności, zwroty, cennik	Błędy zaokrągleń i idempotencji wychodzą po tygodniach, na kontach klientów	Czy każda kwota jest liczona raz, poprawnie zaokrąglona i bezpieczna przy ponowieniu?
Schematy i migracje zmieniające dane produkcyjne	Często nieodwracalne i uruchamiane na danych, których fixture’y nie przypominają	Czy da się ją uruchomić dwa razy i jak ją wycofamy?
Kontrakty publicznego API, SDK i webhooków	Awaria wychodzi w cudzym kodzie, poza testami tego repozytorium	Który istniejący klient się zepsuje i czy to zadeklarowano?
Prywatność i zgodność: usuwanie, eksport, zgody, retencja	Skutkiem jest ryzyko prawne, a nie czerwony test	Czy dane osobowe trafiają tylko tam, gdzie pozwala polityka?
Ochrona przed nadużyciami i incydentami: limity, anti-abuse, nagłówki bezpieczeństwa	Liczą się pod atakiem, którego testy rzadko symulują	Czy pod naciskiem zamyka dostęp, zamiast go otwierać?
Wyrocznia: testy, CI, linter i konfiguracja typów	Zmienia znaczenie „zielonego” dla każdej innej zmiany	Czy zielone wciąż znaczy to samo co wczoraj?
Wszystko, czego nie pokrywa żadne sprawdzenie, albo gdy dowody i agent recenzujący się nie zgadzają	Bez wyroczni jedynym dowodem jest kod	Jak wyglądałby test tego zachowania i kto go napisze?

Pięć wierszy odpowiada tabeli eskalacji na stronie o czytaniu dowodów zamiast kodu, a trzy pochodzą z dawnej checklisty. Zostaw klasę tylko wtedy, gdy odpowiada jej niewielki zestaw ścieżek; lista eskalacji obejmująca pół repozytorium cofa cię na poziom 3. Wymuś listę przez CODEOWNERS plus regułę ochrony gałęzi „Require review from Code Owners”:

.github/CODEOWNERS

/src/auth/            @acme/security-reviewers
/src/billing/         @acme/payments-owners
/db/migrations/       @acme/data-owners
/tests/               @acme/tech-leads
/.github/             @acme/tech-leads

Jak uruchomić agenta recenzującego w Claude Code, Codeksie i Cursorze?

Checklista i ocena są takie same we wszystkich trzech narzędziach. Różni się miejsce, w którym działa agent recenzujący, i to, czy może pisać w pull requeście.

Claude Code

Uruchom checklistę bez interfejsu, z terminala albo z CI. Sesje claude -p startują w trybie uprawnień Manual, więc narzędzia spoza listy dozwolonych są blokowane, chyba że dopuszczają je własne ustawienia projektu z tej gałęzi. Sekcja 4 checklisty uruchamia polecenia testów, sprawdzania typów i lintera oraz zapisuje SHA commita, więc wszystkie muszą być na liście dozwolonych; zamień pisownię npm na polecenia swojego projektu:

# Terminal lub CI, z katalogu głównego repozytorium (Claude Code 2.1.283)
claude -p "$(cat .github/review/agent-checklist.md)" \
  --allowedTools "Read,Grep,Glob,Bash(git diff *),Bash(git log *),Bash(git rev-parse *),Bash(npm test *),Bash(npm run typecheck *),Bash(npm run lint *)" \
  --output-format json --max-budget-usd 2 > review.json

W CI gałąź w review to niezaufane wejście

CLI ładuje z gałęzi jej własne hooki z .claude/settings.json i plik .mcp.json, jej reguły permissions.allow w ustawieniach projektu mogą poszerzyć listę dozwolonych, a dozwolone npm test uruchamia kod tej gałęzi ze wszystkimi sekretami, jakie ma zadanie. W CI dodaj --strict-mcp-config i nie trzymaj sekretów w środowisku zadania. Przy forkach i innych niezaufanych wyzwalaczach pobierz zaufane skrypty z gałęzi domyślnej, commit kontrybutora umieść w osobnym katalogu, który agent tylko czyta, i nie ładuj z niego żadnych ustawień projektu (--bare --setting-sources "" --strict-mcp-config). Testy zostaw zadaniu CI bez uprawnień, a agent niech cytuje jego wyniki.

Drugie przejście pod kątem poprawności daje wbudowane /code-review w sesji. Dla pull requestów z klas eskalacji claude ultrareview 482 uruchamia w chmurze wieloagentowe review pull requesta 482, a każde znalezisko jest niezależnie odtworzone. Po trzech darmowych uruchomieniach na planach Pro i Max jest rozliczane w kredytach użycia (zwykle od 5 do 25 USD za uruchomienie); nie jest dostępne na Bedrocku, Google Cloud i Foundry ani dla organizacji z Zero Data Retention.

Do kroku 4 przyda się plugin Anthropic pr-review-toolkit, skupiony na testach i cichych awariach:

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

Potem, w sesji na gałęzi: /pr-review-toolkit:review-pr tests errors. Zarządzana usługa Code Review (research preview, Team i Enterprise) czyta REVIEW.md, więc skopiuj tam checklistę. Jej check run zawsze kończy się wynikiem neutralnym i nigdy nie blokuje scalenia: traktuj ją jak komentarze, nie bramkę.

Codex

codex exec review przegląda repozytorium bez interakcji i przyjmuje własne instrukcje jako prompt; - czyta je ze standardowego wejścia. Zakres wyznacza pierwsza linia checklisty, „Review the changes on this branch against main”:

# Terminal lub CI, z katalogu głównego repozytorium (Codex CLI 0.157.1)
codex exec review - -c sandbox_mode="workspace-write" -o review.md < .github/review/agent-checklist.md

Sekcja 4 checklisty uruchamia testy, a wiele narzędzi testowych zapisuje cache albo pliki pokrycia, co w piaskownicy tylko do odczytu kończy się błędem; stąd sandbox_mode="workspace-write" (exec review nie ma flagi -s w Codex CLI 0.157.1). W CI traktuj gałąź jako niezaufaną: nie trzymaj sekretów w środowisku zadania, a przy forkach niech testy uruchomi zadanie bez uprawnień, a agent tylko cytuje wyniki.

--base, --commit i --uncommitted to presety, których nie da się łączyć z własnymi instrukcjami (sprawdzone w Codex CLI 0.157.1). Dodaj --output-schema verdict.schema.json, gdy krok CI potrzebuje werdyktu w JSON. Na GitHubie i GitLabie skomentuj pull request @codex review; reguły review są w AGENTS.md (sprawdzone 2026-08-28), więc dopisz tam linię „Apply .github/review/agent-checklist.md to every review”, a obie ścieżki będą stosować ten sam standard.

Cursor

Otwórz agenta na gałęzi pull requesta i wklej pierwszy prompt poniżej; każe on agentowi przeczytać plik checklisty, więc nie trzeba konfigurować reguł. Raport agenta opublikuj jako pierwszy komentarz w pull requeście.

W pull requeście Bugbot szuka błędów i problemów bezpieczeństwa, a PR Routing & Approval przydziela recenzentów według własności kodu i może akceptować pull requesty niskiego ryzyka, które spełniają twoje kryteria (sprawdzone na cursor.com, 2026-08-28). Ustaw tabelę eskalacji jako kryteria akceptacji: automatyczna akceptacja jest dozwolona tylko wtedy, gdy żadna klasa eskalacji nie jest dotknięta. Zobacz PR Routing & Approval w Cursorze.

Uruchamiaj agenta recenzującego w nowej sesji, nie w tej, która napisała kod i przeniosłaby do review te same założenia. Porównanie botów do code review od dostawców narzędzi i firm trzecich pod kątem szumu i konfiguracji znajdziesz w zestawieniu botów do AI code review. Jak podzielić review na osobne przejścia dla poprawności, bezpieczeństwa, testów i zgodności ze specyfikacją przed akceptacją człowieka, opisuje strona o warstwowym review pull requestów.

Prompty do skopiowania do code review PR-a agenta

Prompt do skopiowania: uruchom checklistę agenta recenzującego

Review the changes on this branch against main using the checklist in
.github/review/agent-checklist.md. Read that file first and follow its output
format exactly.

Rules:
- Do not edit, commit, approve, merge or comment on the pull request.
- Run the test, type-check and lint commands from package.json yourself and
  paste each command, its exit status and the commit SHA. Never infer a result.
- Evidence for every item is a command and exit status, a file:line, or a
  search result. "Looks fine" is not evidence.
- Report only findings that could matter in production.

End with the escalation classes touched (with paths) and a suggested verdict:
APPROVE, RETURN or ESCALATE, with a one-sentence reason.

Prompt do skopiowania: wybierz fragmenty do przeczytania przez człowieka

I will read at most three hunks of this branch's diff against main. Choose two
of them for me, applying these rules in order and stopping at the first two
matches: <paste the hotspot order from step 5 of the triage>.

For each hunk give: file and line range, the rule it matched, and the one
question I should answer while reading it. Do not summarise the code; I will
read it myself. Do not choose test files.

Prompt do skopiowania: zwróć pull request agentowi-autorowi

This pull request was returned in review. The failing items are below. Fix
exactly these and nothing else.

<paste the FAIL lines and findings from the review report here>

For each item:
1. Make the smallest change that fixes it.
2. If the item is a missing or weak check, add the test first and show it
   failing on the current code before you fix the code.
3. Do not edit, skip or loosen any existing test, snapshot, CI or lint file.
   If you believe one is wrong, stop and explain why instead of changing it.

When done, rerun the full checklist in .github/review/agent-checklist.md and
update the PR's evidence section with results for the new head commit.

Trzeci prompt służy tylko do pierwszej i drugiej rundy. Po drugim zwrocie człowiek czyta pull request albo przepisuje specyfikację.

Skąd wiesz, że ocena PR-ów działa?

Sama ocena też potrzebuje dowodów. Śledź cztery liczby dla każdej klasy zmian, co miesiąc:

Miara	Definicja	Co mówi zły trend
Trafność próbki	Odsetek przeczytanych fragmentów, w których człowiek znalazł realny problem pominięty przez dowody i agenta recenzującego	Rośnie: dowody mają lukę. Napisz brakujące sprawdzenie i obserwuj, jak wskaźnik spada
Odsetek defektów przepuszczonych na produkcję	Defekty produkcyjne powiązane z pull requestami zaakceptowanymi w ocenie, podzielone przez wszystkie akceptacje z oceny	Rośnie: klasa jest akceptowana za wcześnie; cofnij ją do próbkowania albo pełnego czytania
Rundy zwrotów	Średnia liczba zwrotów na pull request przed akceptacją	Powyżej dwóch: niejasne są specyfikacje, a nie jakość kodu
Precyzja agenta recenzującego	Znaleziska przyjęte przez człowieka podzielone przez wszystkie zgłoszone znaleziska	Spada: checklista produkuje szum; zawęź ją, zanim ludzie przestaną czytać raport

Odpowiedzialność pozostaje jawna: nazwisko osoby akceptującej jest na każdym zaakceptowanym pull requeście, code ownerzy z CODEOWNERS zatwierdzają klasy eskalacji, a tech lead zmienia checklistę i listę eskalacji tylko przez pull requesty, które przeszły review. Kanoniczne wersje tych miar są razem z innymi metrykami zespołu w ramach metryk dla inżynierii agentowej, a etapowe wdrożenie, które przenosi na ten protokół cały zespół, opisuje strona jak pomóc zespołowi przestać czytać każdy diff.

Co się psuje przy ocenie pull requestów agenta?

Agent recenzujący zasypuje cię drobiazgami. Czterdzieści znalezisk, większość o nazewnictwie, a jedyny prawdziwy błąd jest trzydziesty pierwszy. Naprawa: trzymaj się reguły „no style comments” z checklisty, proś tylko o znaleziska P0–P2 i śledź precyzję agenta recenzującego. Gdy spada, usuń punkty checklisty, które produkują szum.

Autor i recenzent mają ten sam martwy punkt. Ten sam model, w tej samej sesji, z tym samym kontekstem dwa razy źle odczytuje specyfikację. Naprawa: uruchamiaj review w nowej sesji, a w klasach eskalacji użyj innego narzędzia albo głębszego przejścia (claude ultrareview, @codex review, Bugbot). Opinia agenta recenzującego nie jest dowodem; są nim tylko sprawdzenia, które się wykonały.

Wyniki dotyczą innego commita. Agent uruchomił testy, potem wypchnął poprawkę, a zielone sprawdzenia należą do poprzedniego commita. Naprawa: wymagaj SHA commita przy każdym poleceniu w raporcie i niech ostatecznym źródłem wyników testów będzie CI, a nie agent.

Próbkowanie zamienia się w przeglądanie po łebkach albo zanika. Pod presją „trzy fragmenty” stają się „rzuciłem okiem”. Naprawa: zapisuj przeczytane fragmenty w komentarzu z werdyktem, losowy plik wybieraj poleceniem, a nie na oko, i licz pull requesty bez zapisanej próbki jako niesprawdzone.

Zwrócone pull requesty kręcą się w kółko. Agent-autor poprawia jedno znalezisko i psuje inne. Naprawa: zatrzymaj się po dwóch zwrotach. Przed trzecią próbą przepisz specyfikację albo jej kryteria akceptacji; zobacz, jak pisać kryteria akceptacji, których agent nie odczyta źle.

Lista eskalacji pochłania wszystko. Każdy pull request dotyka „wspólnego” kodu, więc każdy jest eskalowany, i znowu czytasz diffy. Naprawa: eskaluj według ścieżek w CODEOWNERS, a nie według uznania, i dodawaj klasę tylko przez zmianę tego pliku, która przeszła review.

Wiarygodnie wyglądająca zależność nie istnieje. Kod importuje pakiet o sensownej nazwie, który nigdy nie został opublikowany albo opublikował go atakujący. Naprawa: zachowaj punkt o zależnościach w sekcji 5 checklisty i dodaj do CI sprawdzenie rejestru opisane w kontroli zależności dla zmian agentów.

Dokąd dalej po code review PR-a agenta

Pakiet dowodów Kontrakt pull requesta stojący za krokiem 2 i sprawdzenie CI, które odrzuca niekompletny pakiet.

Czytanie dowodów zamiast kodu Teza, którą ten protokół wprowadza w życie, z osobistym dziennikiem zaufania.

Ochrona wyroczni Jak trzymać sprawdzenia z kroku 4 poza zasięgiem agenta.

Kolejka code review Budżety rozmiaru, ścieżki ryzyka i obciążenie recenzentów, gdy pull requesty otwierają agenci.

Jak pomóc zespołowi przestać czytać każdy diff Etapy shadow, próbkowania i samych dowodów, dla każdej pętli.

Warstwowe review pull requestów Osobne przejścia dla poprawności, bezpieczeństwa, testów i zgodności ze specyfikacją przed akceptacją człowieka.

Ograniczona pętla review i poprawek Automatyzacja ścieżki zwrotu z warunkiem zatrzymania po dwóch rundach.