Was macht PR-Beschreibungsersteller?
Liest den aktuellen Branch-Diff und erstellt eine vollständige GitHub-Pull-Request-Beschreibung. Erstellt oder aktualisiert den PR mit einem einzigen Befehl.
Schreibstil
Anwenden auf alle generierten PR-Beschreibungen:
- Aktivsprache. "Fügt X hinzu" nicht "X wurde hinzugefügt."
- Präsens für Zusammenfassung ("Fügt Caching-Layer hinzu"), Präteritum für Kontext ("Der alte Ansatz verursachte N Requests pro Render")
- Kurze Sätze, eine Idee pro Aufzählungspunkt
- Keine Gedankenstriche – stattdessen Komma oder Punkt verwenden
- Keine Füllwörter: "dieser PR", "dieser Commit", "gemäß der Diskussion"
- Spezifika schlagen Allgemeinplätze: "reduziert p95-Latenz von 800ms auf 90ms" schlägt "verbessert die Leistung"
Schritt 1: Setup prüfen
Stelle sicher, dass gh authentifiziert ist:
gh auth status
Falls nicht authentifiziert: gh auth login und den Anweisungen folgen.
Stelle sicher, dass das aktuelle Verzeichnis ein Git-Repo mit einem aktiven Branch ist:
git branch --show-current
Bei detached HEAD oder keinem Branch anhalten und den Benutzer fragen, welchen Branch er beschreiben möchte.
Schritt 2: Diff-Kontext sammeln
Führe alle drei Befehle aus, um Kontext aufzubauen:
Dateizusammenfassung (was geändert wurde):
git diff main...HEAD --stat
Commit-Nachrichten (warum geändert wurde):
git log main...HEAD --oneline
Vollständiger Diff (wie geändert wurde):
Verwende zuerst origin/main (immer aktuell), fallback auf lokales main, dann master:
if git rev-parse origin/main &>/dev/null 2>&1; then
BASE=origin/main
elif git rev-parse main &>/dev/null 2>&1; then
BASE=main
else
BASE=master
fi
git diff $BASE...HEAD
Wenn der Diff sehr groß ist (über 500 Zeilen), nur die --stat-Zusammenfassung und die Commit-Nachrichten lesen. Auch die ersten 200 Zeilen des Diffs lesen, um die primären Änderungen zu verstehen, ohne die gesamte Ausgabe zu verarbeiten.
Prüfe auch auf einen bestehenden PR und lese dessen aktuellen Titel/Body:
gh pr view --json title,body,baseRefName 2>/dev/null
Schritt 3: Das Format-Handbuch lesen
Lese references/pr-format-guide.md vollständig, bevor du etwas schreibst. Verinnerliche:
- Erforderliche Abschnitte und deren Reihenfolge
- Wie jeder Abschnitt zu schreiben ist
- Was einzuschließen vs. auszulassen ist
- Das Format des Testabschnitts
Schritt 4: Die Beschreibung generieren
Schreibe die PR-Beschreibung mit dem Format aus references/pr-format-guide.md.
Regeln:
- Jeder Aufzählungspunkt im Änderungsabschnitt muss auf etwas im Diff zurückzuführen sein
- Keine Tests erfinden, die nicht durch die Codeänderungen impliziert werden
- Wenn ein Abschnitt keine relevanten Inhalte hat, ihn komplett weglassen (nicht "N/A" oder leer lassen)
- Screenshot-Abschnitt: nur einfügen, wenn UI-Änderungen im Diff sichtbar sind
- Wenn Commit-Nachrichten das "Warum" erklären, diesen Kontext in der Zusammenfassung verwenden
Qualitätskontrolle: Vor der Präsentation überprüfen:
- [] Zusammenfassung 1-2 Sätze, Aktivsprache, keine Füllwörter
- [] Jeder Änderungspunkt ist spezifisch und auf den Diff zurückzuführen
- [] Keine erfundenen Metriken oder Ergebnisse
- [] Tests sind umsetzbar (jemand könnte sie befolgen)
- [] Keine Gedankenstriche in einer Zeile
Schritt 5: PR erstellen oder aktualisieren
Lege dem Benutzer die Beschreibung vor und frage: "Bereit, den PR zu erstellen, den vorhandenen zu aktualisieren oder nur auszugeben?"
Neuen PR erstellen:
Den Body über stdin übergeben, um Backticks, Anführungszeichen und Zeilenumbrüche sicher zu handhaben:
gh pr create --title "TITEL_HIER" --body-file - << 'EOF'
BODY_HIER
EOF
Einen Titel basierend auf den Commit-Nachrichten und der Diff-Zusammenfassung vorschlagen. Der Titel sollte im Imperativ und unter 72 Zeichen sein: "Redis-Caching für Benutzersitzungs-Suchvorgänge hinzufügen" nicht "Caching hinzugefügt".
Vorhandenen PR aktualisieren:
gh pr edit --body-file - << 'EOF'
BODY_HIER
EOF
Nur ausgeben: Titel und Body in einem Code-Block zur manuellen Kopie präsentieren.
Nach dem Erstellen oder Aktualisieren bestätigen: "PR-Beschreibung aktualisiert. Ansehen unter: [URL]"