PR-Erklärer + Verständnis-Quiz

Was macht PR-Erklärer + Verständnis-Quiz?

Durch KI unterstütztes Programmieren macht es leicht, Code zu genehmigen, den man nie wirklich verstanden hat. Dieses Skill erklärt eine Änderung auf dem Niveau, das ein Reviewer braucht, und überprüft dann das Verständnis mit einigen gezielten Fragen – damit „LGTM“ auch etwas bedeutet.

1. Sammle die Änderung

Wähle die zutreffende Methode:

gh pr view <num> --json title,body,baseRefName,headRefName,files   # GitHub PR
gh pr diff <num>
git diff <base>...<head>                                            # Branch
git show <sha>                                                     # Einzelner Commit

Lies die PR-Beschreibung und ggf. das verknüpfte Issue. Lies dann den umgebenden Code der geänderten Funktionen (Aufrufer, Aufgerufene, Tests) – ein Diff allein verbirgt den Kontext, der zählt.

2. Erkläre – in dieser Reihenfolge

1. Ein-Absatz-Zusammenfassung: Welches Verhalten ändert sich für einen Benutzer oder Aufrufer? Keine Liste von Dateien.
2. Warum: Das gelöste Problem, aus der Beschreibung/dem Issue/den Commit-Nachrichten. Wenn der Grund nirgendwo genannt wird, sag das – das ist ein Review-Fund.
3. Diagramm: Ein Mermaid-sequenceDiagram oder flowchart des neuen Ablaufs, wobei das Neue/Geänderte hervorgehoben wird (mit einer Notiz oder der Klasse :::changed). Bleib unter ~15 Knoten; zeichne den Kernpfad, nicht alles.
4. Walkthrough nach Konzept, nicht nach Datei: Gruppiere zusammenhängende Hunk-Blöcke („die Wiederholungslogik“, „das neue Konfigurations-Flag“). Erkläre zu jedem, was es tut, und alles Nicht-Offensichtliche (Nebenläufigkeit, Fehlerbehandlung, Randfälle, Leistung).
5. Risikohinweise: Dinge, die ein Reviewer am genauesten ansehen sollte – geänderte öffentliche Schnittstellen, Migrationen, gelöschte Tests, verschluckte Fehlerpfade, sicherheitsrelevanter Code, fehlende Tests für neue Verzweigungen. Sei konkret mit Datei:Zeile.

3. Quiz

Stelle 3–5 Fragen, eine nach der anderen, und warte auf die Antwort, bevor du die nächste stellst. Gute Fragen erfordern Verständnis, nicht Auswendiglernen:

• „Was passiert jetzt, wenn <Abhängigkeit> während <Operation> timeoutet?“
• „Welcher bestehende Aufrufer ist von der Signaturänderung betroffen – und wie?“
• „Warum muss <Zeile> vor <Zeile> kommen?“
• „Wenn wir das nach der Migration zurückrollen, was geht dann kaputt?“

Vermeide triviales Wissen („Wie heißt die neue Funktion?“). Mische: mindestens eine Frage zu Fehler-/Randverhalten, eine zu einer Designentscheidung.

Nach jeder Antwort: Sag, ob sie richtig ist, und gib die richtige Erklärung in 1–3 Sätzen mit einem Code-Verweis. Liegt der Benutzer bei etwas Wichtigem falsch, schlage vor, welchen Teil des Diffs er nochmal lesen sollte.

4. Abschluss

Bewertung (z. B. 4/5) und ein kurzes Urteil: „bereit zum Review“ oder „lies X nochmal vor der Genehmigung“. Biete an, Review-Kommentare für gefundene Risiken zu entwerfen.

Umfang auf die Anfrage abstimmen

Der vollständige Ablauf (Zusammenfassung → Warum → Diagramm → Walkthrough → Risiken → Quiz) ist die Voreinstellung für „Erklär mir das“ oder „Hilf mir beim Review“. Wenn der Benutzer die Anfrage eingrenzt, respektiere das:

• „kein Quiz“ / „Quiz überspringen“: Schritte 1–2 ohne Schritt 3.
• „nur Zusammenfassung und Risiken“: die Ein-Absatz-Zusammenfassung und die Risikohinweise, sonst nichts: kein Diagramm, kein Walkthrough. Biete den Rest in einem abschließenden Satz an.
• „nur das Diagramm“: das Diagramm plus eine Bildunterschrift von zwei Sätzen.

Das erste aufgeführte Risiko sollte dasjenige sein, das das Verhalten für Benutzer oder Geldbeträge ändert (z. B. eine stille falsche Abbuchung), nicht das technisch interessanteste.