KI-gestützte Review nutzen

Diese Anleitung zeigt, wie Reviewer-Agenten einen Pull Request prüfen und wie du das Ergebnis auf GitHub veröffentlichst.

Ein KI-Review starten

Öffne den PR und wechsle auf den Tab Übersicht
Öffne in der Aktionszeile das Menü ⋯ und wähle Ask AI

Der Eintrag erscheint nur, solange der PR offen ist. Es ist eine Aktion vor dem Merge. Dieselbe Schaltfläche steht als Ask AI im Leerzustand des Tabs Review, bevor ein Review existiert.

Control Center startet die mitgelieferte Pipeline pr_review und öffnet den Tab Review des PR, damit du zusehen kannst. Die Pipeline:

Öffnet den eigenen Review-Bereich des PR. Dessen isolierter Worktree hat den PR an seinem Head ausgecheckt
Schickt die Reviewer für die Review-Stufe des Arbeitsbereichs los, standardmäßig drei (die mitgelieferten Agenten qa, architect und engineer, parallel). Es gibt keine Sprach- oder Domänenerkennung
Lässt den Lead-Agenten (CEO) ihre Befunde zu einem Walkthrough zusammenfassen
Finalisiert: sortiert die Befunde in Konsens-Gruppen und berechnet das Verdikt. Erreicht die Zuordnung awaiting approval, erscheint Auf GitHub veröffentlichen auf dem Tab Review

Wie tief das Review geht, ist die Review-Stufe des Arbeitsbereichs: light (ein Reviewer), balanced (drei, der Standard) oder thorough (alle fünf, dazu die Spezialisten für Sicherheit und Performance). Eingestellt wird sie unter Einstellungen → Arbeitsbereich → Allgemein, auf der Karte Arbeitsbereichs-Richtlinien. Eine leichtere Stufe erfasst genauso viele Befunde und stellt weniger davon in den Vordergrund.

Alle Reviewer schreiben in den einen Review-Bereich des PR. Genau das macht ihre Befunde vergleichbar. Siehe KI-Review dafür, wie die Teile zusammenpassen.

pr_review bringt nur einen manuellen Trigger mit. Damit sie bei jedem veröffentlichten PR startet, legst du selbst einen Trigger an. Siehe Reviewer-Agenten starten. Du kannst eines auch direkt von GitHub aus starten, ohne Pipeline-Trigger: erwähne den Bot des Servers auf dem PR oder setze das Label ai-review. Siehe Aus einem GitHub-PR mit Control Center sprechen.

Sagt ein Toast „Für diesen Pull-Request läuft bereits ein Review“, ist schon eines unterwegs. Bleib auf dem Tab Review oder öffne Pipelines, um es zu finden.

Die Befunde lesen

Reviewer erfassen Befunde als Review-Knoten im Review-Bereich. Jeder trägt:

Feld	Beschreibung
Art	`bug`, `suggestion`, `recommendation`, `question` oder `ticket`
Priorität	P0 (kritisch) → P3 (Kleinigkeit)
Kategorie	`security`, `stability`, `data_integrity`, `correctness`, `performance` oder `maintainability`
Datei und Zeile	Wo der Befund verankert ist
Ursprünglicher Code	Der Code, um den es im Befund geht
Vorgeschlagener Code	Die vorgeschlagene Korrektur
Konfidenz	Wie sicher sich der Reviewer ist
Status	`open` → `consensus-ready` → `resolved` oder `dismissed`

Ein Befund erreicht consensus-ready erst, wenn ein Peer-Reviewer ihn bestätigt. Ein Agent kann den eigenen Befund nicht bestätigen, also steigt die Einschätzung eines einzelnen Reviewers nie von allein auf.

Der Tab Review zeigt die Befundliste, filterbar nach Art und Status, mit einem Schalter für verworfene Befunde, neben dem Artefakt, das der konsolidierende Agent veröffentlicht hat. Die deterministische Ansicht, Kohorten, das Dashboard über mehrere Achsen, Vertrags- und visuelle Diffs, berechnet der Server. In der App hat sie keine Oberfläche. Siehe Review-Compute dafür, was der Durchgang erzeugt.

Das Widerspruchs-Panel prüfen

Wenn zwei Reviewer Befunde an derselben Datei und Zeile verankern, sie aber sehr unterschiedlich bewerten, Prioritäten um mindestens zwei Stufen auseinander oder einer sagt bug und der andere suggestion, erscheint ein Widerspruchs-Panel über der Befundliste. Lies die zuerst: dort laufen die Einschätzungen auseinander, und dein Urteil ist am meisten wert.

Das Verdikt lesen

Wenn der Lead-Agent finalisiert, berechnet er ein Verdikt:

Verdikt	Bedeutung
Ship	Nichts Blockierendes gefunden
Hold	Punkte, die vor dem Merge behoben werden sollten
Block	Kritische Punkte, die behoben werden müssen

Das Verdikt trägt eine aggregierte Konfidenz und die Befundzahlen je Priorität.

Danach fließen die Review-Achsen ein, und sie können das Verdikt nur strenger machen. Eine Achse mit Gate, die fehlschlägt, erzwingt Block. Eine Achse mit Gate, die nicht zu Ende kam (partial) oder gar nicht laufen konnte (unavailable), erzwingt mindestens Hold. Fehlende Evidenz hebt ein Gate nie auf.

Das Review auf GitHub veröffentlichen

Veröffentlichen ist ein eigener Schritt, den du bewusst auslöst. Die Pipeline pr_review behält das Review in Control Center. Nach GitHub postet sie nicht.

Warte auf dem Tab Review, bis Auf GitHub veröffentlichen erscheint
Drücke Auf GitHub veröffentlichen

Control Center sendet ein GitHub-Review. Schon erledigte oder abgelehnte Befunde werden übersprungen. Die Schaltfläche nimmt jeden verbleibenden offenen Befund mit und reicht bei Ship APPROVE ein. (Das MCP-Tool publish_review_to_github bleibt standardmäßig bei nur von einem Peer bestätigten Befunden und gibt nicht frei, solange du nicht approve_on_ship übergibst.) Befunde mit Anker auf Datei und Zeile werden Inline-Kommentare. Alles andere wandert in den Text der Zusammenfassung, jeder mit der Fußzeile “— Control Center AI review”, damit die Quelle eindeutig ist. Ein Verdikt Block wird als REQUEST_CHANGES eingereicht, Hold als COMMENT und Ship als APPROVE von dieser Schaltfläche. Ein Toast zeigt danach Veröffentlicht. Das Review wird unter der App-Identität des Servers gepostet.

Lehnt GitHub einen Inline-Anker ab, weil die Zeile nicht zum Diff gehört, wird das gesamte Review erneut gesendet und jeder Befund in den Text genommen, damit nichts stillschweigend verloren geht.

Andere mitgelieferte Pipelines posten direkt nach GitHub: cross_review, pr_triage, ticket_to_pr und pre_merge_gate enden jeweils in einem Kommentarschritt. Nur pr_review hält die Ausgabe für dich zurück.

Reviewer selbst starten

Wenn du steuern willst, welche Rollen den PR prüfen und welche Dateien jede davon ansieht, nutze das MCP-Tool dispatch_reviewers in einem bestehenden Review-Bereich oder füge einer Pipeline Reviewer-Knoten hinzu. Beide Wege, mit der genauen Signatur des Tools, stehen in Reviewer-Agenten starten.