agentkitco/agentkit-dev-skills

Erstelle einen Pull-Request-Titel und eine Beschreibung basierend auf dem tatsächlichen Diff und den Commits – inklusive Änderungen, Grund, Testmethode und Prüfhinweisen. Verwende diese Fähigkeit, wenn du gebeten wirst, eine PR-Beschreibung zu schreiben oder zu verbessern.

Was ist agentkit-dev-skills?

Diese Fähigkeit hilft Entwicklern und KI-Agenten, automatisch eine aussagekräftige Pull-Request-Beschreibung aus dem aktuellen Diff und den Commits zu generieren. Das Ziel ist es, einem Reviewer in zwei Minuten klarzumachen, worauf er achten soll, und zukünftigen Lesern den Grund für die Änderung zu erklären. Dazu werden der Basis-Branch ermittelt, die Änderungen mit `git log` und `git diff` analysiert, sowie relevante Issue-Nummern, Kommentare oder Testdateien aus dem Diff extrahiert. Falls ein `PULL_REQUEST_TEMPLATE` vorhanden ist, wird dieses ausgefüllt, ansonsten folgt die Beschreibung einer klaren Struktur mit Abschnitten wie „Why“, „What changed“, „How to review“, „Testing“ und „Rollout / risk“. Die Fähigkeit unterstützt alle gängigen Git-basierten Plattformen (GitHub, GitLab, Bitbucket etc.) und setzt auf strikte Regeln: Keine erfundenen Motivationen, keine Listen von Dateien, keine Füllwörter oder Emojis – nur präzise, faktenbasierte Zusammenfassungen der tatsächlichen Änderungen.

Funktioniert mit~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/agentkitco/agentkit-dev-skills/tree/HEAD/skills/pr-description

Dokumentation

Schreibe eine PR-Beschreibung, die ein Reviewer nutzen kann

Ziel: Einem Reviewer in zwei Minuten klar machen, worauf er achten soll, und zukünftigen Lesern den Grund für die Änderung verständlich machen.

Sammeln

Finde den Basis-Branch und führe git log --oneline <base>..HEAD und git diff --stat <base>...HEAD aus, lies dann den Diff.
Suche nach dem Grund: verknüpfte Issue- oder Ticketnummer in Commits oder Branch-Namen, die Anfrage des Benutzers, Kommentare im Diff. Wenn der Grund in keinem davon enthalten ist, frage den Benutzer; erfinde keine Motivation.
Überprüfe, was getestet wurde: Testdateien im Diff und Befehle, die der Benutzer ausgeführt hat. Wenn keine Tests durchgeführt wurden, sage das deutlich.
Suche nach einer .github/pull_request_template.md oder PULL_REQUEST_TEMPLATE. Wenn eine vorhanden ist, fülle diese aus, anstatt die untenstehende Struktur zu verwenden.

Struktur

<Titel: imperativ, unter 70 Zeichen, benennt die Verhaltensänderung, nicht die Dateien>

## Warum
<Das Problem oder die Anfrage, in 1 bis 3 Sätzen. Verlinke das Issue, falls vorhanden.>

## Was geändert wurde
- <Verhaltensbezogene Aufzählungspunkte, gruppiert nach Bereich, keine Dateiliste.>

## Wie zu reviewen
- Beginne mit <Datei oder Bereich>; der Rest ergibt sich daraus.
- Riskanter Teil: <Der Teil, der am wahrscheinlichsten falsch ist, und warum.>
- Absichtlich nicht geändert: <Alles, was ein Reviewer erwarten könnte und nicht finden wird.>

## Testen
- <Genau ausgeführte Befehle und Ergebnisse.>
- <Manuelle Schritte und was gesehen wurde. „Nicht getestet: ...“ falls zutreffend.>

## Ausrollen / Risiko
<Migrationen, Konfiguration, Feature-Flags, Kompatibilität, Rückrollmethode. „Keine“ nur, wenn es zutrifft.>

Regeln

Beschreibe, was der Diff tut, nicht, was du dir wünschst, dass er tut. Lies den Diff nach dem Entwurf erneut und lösche jede Behauptung, die er nicht stützt.
Liste nicht jede Datei auf. Liste dafür Verhaltensänderungen, neue Konfiguration, neue Abhängigkeiten und gelöschten Code auf.
Keine Füllwörter („Dieser PR zielt darauf ab...“). Keine Emojis, es sei denn, das Repository verwendet sie.
Screenshots oder Ausgabebeispiele: Gib an, wo eines helfen würde; beschreibe niemals einen Screenshot, den du nicht gesehen hast.
Gib Titel und Text in einem Codeblock aus, damit sie kopiert werden können. Führe gh pr create nur aus, wenn du darum gebeten wirst.