Använd AI-driven granskning

Den här guiden visar hur du låter granskaragenter granska en pull request och hur du publicerar resultatet till GitHub.

Starta en AI-granskning

Öppna PR:en och gå till fliken Översikt
Öppna överflödesmenyn ⋯ på åtgärdsraden och välj Fråga AI

Posten visas bara medan PR:en är öppen – det är en åtgärd före sammanslagning. Samma knapp erbjuds som Fråga AI i det tomma tillståndet på fliken Granskning, innan någon granskning finns.

Control Center startar den medföljande pr_review-pipelinen och öppnar PR:ens flik Granskning så att du kan följa den. Pipelinen:

Öppnar PR:ens egen granskningsyta, vars isolerade worktree har PR:en utcheckad på sin head
Skickar ut granskarna för arbetsytans granskningsnivå – tre som standard (de medföljande agenterna qa, arkitekt och ingenjör, parallellt). Det finns ingen språk- eller domänigenkänning
Låter huvudagenten (CEO) sammanställa deras fynd till en genomgång
Finaliserar: sorterar fynden i konsensusgrupper och räknar fram utfallet. När kopplingen når awaiting approval visas Publicera till GitHub på fliken Granskning

Hur djupt granskningen går styrs av arbetsytans granskningsnivå – light (en granskare), balanced (tre, standard) eller thorough (alla fem, med säkerhets- och prestandaspecialisterna) – som ställs in under Inställningar → Arbetsyta → Allmänt, på kortet Arbetsytepolicy. En lättare nivå registrerar precis lika många fynd; den rapporterar bara färre av dem i förgrunden.

Alla granskare postar i PR:ens enda granskningsyta, och det är vad som gör deras fynd jämförbara. Se AI-granskning för hur delarna hänger ihop.

pr_review levereras bara med en manuell trigger. Om du vill att den ska köras på varje publicerad PR lägger du till en trigger själv – se Starta granskningsagenter. Du kan också starta en från GitHub själv, utan pipelinetrigger: nämn serverns bot i PR:en eller lägg till etiketten ai-review – se Prata med Control Center från en GitHub-PR.

Om en toast säger att en granskning redan körs för den här pull requesten är en redan i gång; stanna på fliken Granskning eller öppna Pipelines för att hitta den.

Läs fynden

Granskare registrerar fynd som granskningsnoder i granskningsytan. Var och en innehåller:

Fält	Beskrivning
Typ	`bug`, `suggestion`, `recommendation`, `question` eller `ticket`
Prioritet	P0 (kritisk) → P3 (petitess)
Kategori	`security`, `stability`, `data_integrity`, `correctness`, `performance` eller `maintainability`
Fil och rad	Var fyndet är ankrat
Ursprunglig kod	Koden som fyndet handlar om
Föreslagen kod	Den föreslagna åtgärden
Konfidens	Hur säker granskaren är
Status	`open` → `consensus-ready` → `resolved` eller `dismissed`

Ett fynd når bara consensus-ready när en _kollega_granskare bekräftar det. En agent kan inte bekräfta sitt eget fynd, så en enskild granskares åsikt avancerar aldrig på egen hand.

Fliken Granskning visar fyndlistan, filtrerbar på typ och status, med en växel för avvisade fynd, bredvid artefakten som den sammanställande agenten publicerade. Den deterministiska vyn – kohorter, instrumentpanelen med flera axlar, kontrakts- och visuella diffar – beräknas på serversidan men har ingen yta i appen; se Granskningsberäkning för vad körningen producerar.

Kontrollera oenighetspanelen

När två granskare ankrar fynd till samma fil och rad men bedömer dem väldigt olika – prioriteringar två eller fler nivåer isär, eller att en kallar det en bug medan den andra kallar det en suggestion – visas en oenighetspanel ovanför fyndlistan. Läs dem först: det är där granskarnas åsikter går isär och ditt omdöme är värt som mest.

Läs utfallet

När huvudagenten finaliserar räknar den fram ett utfall:

Utfall	Betydelse
Ship	Inget blockerande hittades
Hold	Problem som bör åtgärdas före sammanslagning
Block	Kritiska problem som måste åtgärdas

Utfallet bär ett sammanvägt konfidensvärde och antal fynd per prioritet.

Granskningsaxlarna vävs sedan in i det och kan bara göra det mer allvarligt. En grindad axel som fallerar tvingar fram Block; en grindad axel som inte kunde slutföras (partial) eller inte kunde köras alls (unavailable) tvingar fram minst Hold. Frånvaro av bevis blir aldrig en grön grind.

Publicera granskningen till GitHub

Publiceringen är ett separat steg som medvetet grindas av användaren. Pipelinen pr_review behåller granskningen i Control Center; den lägger inte upp något på GitHub.

Vänta på fliken Granskning tills Publicera till GitHub visas
Tryck på Publicera till GitHub

Control Center skickar en GitHub-granskning. Fynd som redan är åtgärdade eller avvisade hoppas över. Knappen inkluderar varje återstående öppet fynd och skickar APPROVE vid Ship. (MCP-verktyget publish_review_to_github använder fortfarande som standard bara kollegabekräftade fynd och godkänner inte om du inte skickar med approve_on_ship.) De som bär ett ankare till fil och rad blir inline-kommentarer; allt annat vävs in i sammanfattningstexten, och var och en bär en “— Control Center AI review”-fotnot så att källan är entydig. Ett Block-utfall skickas in som REQUEST_CHANGES; Hold som COMMENT; Ship som APPROVE från den här knappen. En toast visar sedan Publicerad. Granskningen publiceras under serverns appidentitet.

Om GitHub avvisar ett inline-ankare för att raden inte ingår i diffen skickas hela granskningen om med varje fynd invävt i texten, så att inget tyst tappas bort.

Andra inbyggda pipelines lägger faktiskt upp på GitHub direkt: cross_review, pr_triage, ticket_to_pr och pre_merge_gate slutar alla i ett kommentarssteg. Bara pr_review håller tillbaka sin utdata åt dig.

Starta granskningsagenter själv

För kontroll över vilka roller som granskar PR:en och vilka filer var och en tittar på använder du MCP-verktyget dispatch_reviewers inuti en befintlig granskningsyta, eller lägger till granskarnoder i en pipeline. Båda vägarna, med verktygets exakta signatur, finns i Starta granskningsagenter.