PR-Review (Pull-Request-Überprüfung)

PR-Review

Verfahren zum Reviewen eines Pull-Requests. Die Review-Regeln (Ton, Kommentarkategorien, Entscheidungsablauf, was nicht zu tun ist) stehen im Playbook unter „PR Reviews“; dieses Skill beschreibt das Wie. Wiederhole hier keine Regeln, sondern wende sie an. Die „Shared Standards“ des Playbooks gelten durchgängig (präzise, kein KI-Geschwafel, überprüfen statt behaupten, niemals etwas erfinden).

Vor dem Review

1. Fordere zuerst das Ticket an. Gemäß dem obligatorischen ersten Schritt des Playbooks darfst du den Diff erst holen oder analysieren, wenn du das Ticket hast. Das Ticket legt den Arbeitstyp fest (Feature vs. Follow‑up vs. Investigation) und die Akzeptanzkriterien, die deine Review beeinflussen.
2. Identifiziere den PR: Frage nach der PR‑Nummer/URL, falls diese nicht gegeben ist.

Kontext sammeln

• Hole den Diff und die Metadaten mit der GitHub‑CLI: gh pr view <pr> und gh pr diff <pr>.
• Überprüfe bei einem Investigation‑PR auch docs/investigations/ auf das erwartete Format.
• Lies die geänderten Dateien vollständig, nicht nur die Diff‑Hunks, wenn das Verhalten vom umgebenden Code abhängt.

Review

Gehe den Diff Datei für Datei durch. Wende den Abschnitt „PR Reviews“ des Playbooks an:

• Führe die Playbook‑Checkliste aus (Akzeptanzkriterien, Kompilierungs‑/Testfehler, Aktualisierung von Aufrufern, Testabdeckung, Nachweise für Investigations).
• Klassifiziere jeden Befund als blockierend, Nitt oder Frage, gemäß Playbook.
• Verwende den Entscheidungsablauf des Playbooks, um zu entscheiden, ob eine Beobachtung einen Kommentar wert ist.
• Die Umfangsregeln unterscheiden sich je nach Tickettyp (Follow‑up: alles hier klären; Feature: Refactorings sind gültig). Bestätige den Typ aus dem Ticket.
• Gemäß „Überprüfen, nicht behaupten“ des Playbooks: Prüfe Behauptungen selbst, bevor du sie wiedergibst. Führe gh pr checks <pr> für CI aus, durchsuche das Repository nach entfernten Symbolen. Die PR‑Beschreibung ist die Behauptung des Autors, kein Beleg.
• Gemäß „Bestehendes Verhalten nicht stillschweigend entfernen“ des Playbooks: Eine unbestätigte Verhaltensregression ist ein blockierender Befund, selbst wenn der Autor sie in der Beschreibung markiert hat.

Ausgabe

Befolge das Playbook „PR Reviews > Format“. Gib die Review direkt im Chat aus (nicht als Datei, es sei denn, der Benutzer wünscht eine), als einzeiliges Urteil und danach die Befunde. Es ist kein prosaartiger Aufsatz, kein Gesprächsprotokoll und hat keine Abschnitte wie „Gesammelter Kontext“/„Erste Überprüfung“. Jeder Befund besteht aus: einer Referenz auf Ort+Codezeile, dem Kommentar in einem kopierbaren Codeblock und der Begründung. Konkret sieht ein Befund so aus:

### Blocking

`internal/adapters/users/adapter.go:281`
```go
_, err := u.providersClient.Update(ctx, request)
```

Kommentar (zum Einfügen in den PR):

Dies entfernt die Wiederholungslogik für die Eventual‑Consistency, auf die diese Schreibvorgänge angewiesen sind. Die Core→Users‑Verzögerung zeigt sich als NotFound, den die neue Nur‑Transient‑Richtlinie nicht wiederholen wird, sodass der Schreibvorgang sofort fehlschlägt.

Begründung: AC #3 verlangt zu bestätigen, dass kein Pfad auf das Wiederholen von Anwendungsfehlern angewiesen ist; dieser Pfad war es, und der Diff entfernt es, ohne zu bestätigen, dass das Fenster verschwunden ist.
````

Wiederhole einen solchen Block pro Befund, gruppiert unter `### Blocking` / `### Nits` / `### Questions` (leere Gruppen weglassen). Der Codeblock nach „Kommentar“ ist das Einzige, was der Benutzer nach GitHub kopiert; alles andere dient der Navigation. Wenn alles gut ist, genügt die Urteilszeile.

## Posten (nur auf Anfrage)

Wenn der Benutzer Kommentare im PR posten statt im Chat entwerfen möchte, bestätige zuerst, verwende dann `gh pr review` / `gh pr comment`. Standardmäßig wird im Chat entworfen.