Whitepaper / E-Book Gliederung
Perspektivwechsel

Code Review Feedback formulieren

Aus Diff und Notizen wird ein fertiger Review-Kommentar

So funktioniert dieser Skill

  1. 1Diff und NotizenCode-Diff, PR-Beschreibung und deine groben Review-Anmerkungen in den Chat geben
  2. 2Diff verstehenPR-Beschreibung und Feature-Kontext lesen, den Diff durchgehen und auch finden, was in deinen Notizen fehlt
  3. 3Positives sichernGute Lösungen, saubere Patterns und Testabdeckung ausdrücklich benennen
  4. 4Nach Schwere sortierenJede Anmerkung als Must-fix, Should-fix oder Nice-to-have einordnen, begründen und, wo es geht, einen Gegenvorschlag anhängen
  5. 5Fragen an den AutorUnklares als Frage formulieren, statt es als Annahme in die Kritik zu schreiben
  6. 6Empfehlung setzenApprove, Request Changes oder Comment, jeweils mit kurzer Begründung
  7. 7Review-KommentarZusammenfassung, Lob, drei Schwere-Stufen, Fragen und Empfehlung in einem Text
  8. 8Prüfen und postenTon an eure Team-Kultur anpassen und den Kommentar in den Pull Request stellen

Prompt zum Kopieren

Trag deine Angaben ein oder klick auf einen Namen im Text. Alles bleibt in deinem Browser — wir sehen und speichern es nicht.

# BESCHREIBUNG
Formuliert konstruktives Code-Review-Feedback mit kategorisierten Anmerkungen nach Schwere, Begründungen und konkreten Verbesserungsvorschlägen – in respektvollem, lernförderndem Ton.

# EINGABE
- Code-Diff / PR-Beschreibung (Pflicht)
- Review-Anmerkungen (grobe Notizen, Bedenken) (Pflicht)
- Code-Standards des Teams: Coding Standards (optional)
- Kontext des Features: Feature Kontext (optional)

# AUSGABE
Strukturiertes Code-Review-Feedback:
1. Zusammenfassung – Gesamteindruck des PRs
2. Positives Feedback – Was ist gut gelöst?
3. Must-fix – Bugs, Sicherheitslücken, Breaking Changes
4. Should-fix – Performance, Wartbarkeit, Best Practices
5. Nice-to-have – Stilistische Verbesserungen
6. Fragen – Verständnisfragen an den Autor
7. Empfehlung – Approve / Request Changes / Comment

# KONTEXT
- Code Reviews sind Qualitätssicherung UND Lerninstrument
- "Warum" ist wichtiger als "Was" – immer begründen
- Positives Feedback motiviert und verstärkt gute Practices
- Must-fix vs. Nice-to-have klar trennen

# ARBEITSANWEISUNG
## Schritt 1: Code-Diff und Feature-Kontext verstehen
PR-Beschreibung lesen, Feature-Kontext erfassen und den Code-Diff analysieren.

## Schritt 2: Positive Aspekte identifizieren
Gute Lösungen, saubere Patterns und Testabdeckung anerkennen.

## Schritt 3: Anmerkungen kategorisieren und begründen
Jede Anmerkung als Must-fix, Should-fix oder Nice-to-have einordnen. Immer das "Warum" erklären und konkrete Alternativen vorschlagen.

## Schritt 4: Verständnisfragen formulieren
Bei Unklarheiten Fragen stellen statt Annahmen treffen.

## Schritt 5: Klare Empfehlung geben
Approve, Request Changes oder Comment – mit kurzer Begründung.

# DEFINITION OF DONE
[ ] Positives Feedback enthalten
[ ] Anmerkungen nach Severity kategorisiert
[ ] Jeder Kommentar hat eine Begründung
[ ] Ton ist konstruktiv und respektvoll
[ ] Klare Empfehlung gegeben

# GESPRÄCHSSTART
Beginne das Gespräch mit genau diesen Sätzen:
Hey Dein Name! Ich formuliere dein Review-Feedback – Kontext: Feature Kontext, eure Standards habe ich: Coding Standards. Schick mir den Code-Diff und deine Anmerkungen, dann sortiere ich sie nach Must-fix, Should-fix und Nice-to-have, begründe jede einzeln und gebe dir am Ende eine klare Empfehlung.

Was der Skill genau macht

Ein Review-Kommentar entscheidet mit darüber, ob aus einer Anmerkung eine Verbesserung wird oder stiller Ärger. Die meisten scheitern nicht am Fachlichen: Sie listen drei Zeilen ohne Begründung, stellen Sicherheitslücke und Namensgeschmack nebeneinander und verlieren kein Wort über das, was gut gelöst war.

Der Skill nimmt deinen Code-Diff und deine rohen Notizen und baut daraus einen fertigen Kommentar für den Pull Request. Jede Anmerkung landet in einer von drei Stufen – Must-fix, Should-fix, Nice-to-have –, bekommt ihr „Warum“ und, wo es geht, einen konkreten Gegenvorschlag. Was gut gelöst ist, steht ausdrücklich drin. Unklares geht als Frage an den Autor statt als Annahme in die Kritik. Und am Ende steht eine Empfehlung: Approve, Request Changes oder Comment.

Gedacht für alle, die regelmäßig Pull Requests durchsehen – besonders dort, wo Junioren mitlesen und ein Review auch Lehrstoff ist. Für Feedback an Menschen, also Gespräche, Beurteilungen und Entwicklungsschritte, gibt es einen eigenen Skill; dieser hier bleibt am Code.

So arbeitest du damit

  1. Das brauchst du.
  2. Angaben oben ausfüllen und Prompt kopieren —deine Angaben setzen sich beim Kopieren mit ein. Den Prompt selbst kannst du dabei frei ändern — kürzen, ergänzen, umschreiben.
  3. In dein Tool der Wahl einsetzen.
    1. Kopiere den Skill-Text oben über den Kopieren-Button.
    2. Klicke auf dein Profilbild und wähle „Skills“.
    3. Klicke auf „Skill erstellen“ und füge den kopierten Skill-Text als Anweisung ein.
    4. Passe bei Bedarf Eingaben, Ausgaben und das gewünschte Format an.
    5. Speichere den Skill — er ist sofort in allen Chats verfügbar.
    OpenAI Dokumentation: Skills in ChatGPT
  1. Must-fix-Liste gegenlesen: Prüf bei jedem Punkt, ob er den Merge wirklich blockiert. Der Skill stuft im Zweifel hoch, und vier Must-fixes lesen sich für den Autor als Ablehnung, auch wenn zusammen nur fünfzehn Zeilen Arbeit dahinterstecken.
  2. Ergänzte Punkte einordnen: Der Skill findet auch, was in deinen Notizen gar nicht stand. Entscheide selbst, ob das in diesen Review gehört oder in ein eigenes Ticket – ein Review, das alles auf einmal will, wird nicht abgearbeitet.
  3. Fragen zuerst stellen: Die Verständnisfragen stehen genau dort, wo der Diff keine Antwort hergab. Ohne sie entscheidest du über Code, den du nicht ganz gesehen hast.
  4. Als Kommentar in den PR stellen: Die Must-fix-Punkte an die Codestelle als Inline-Kommentar, den Rest als Gesamtkommentar. Dann muss der Autor nichts suchen.
  5. Bei einem ersten PR kurz sprechen: „Request Changes“ liest sich beim ersten Mal härter, als es gemeint ist. Zwei Sätze vorab nehmen dem Kommentar die Schärfe, ohne einen Punkt davon zurückzunehmen.
  6. Wenn es hakt: Alles landet unter Must-fix (Notizen vorsortieren und den Feature-Kontext ausfüllen), Begründungen bleiben allgemein (Team-Standards ins Feld eintragen – dann zitiert der Skill eure Regel statt einer Lehrbuchregel), Kein Lob im Ergebnis (dann steht im Diff wirklich nichts Gutes; erfinden lassen ist schlechter als weglassen).
  7. Ausbauen: Review-Checkliste des Teams als feste Ergänzung mitgeben, Zweiter Durchgang nur für die Tests, Kurzfassung für den Autor neben dem ausführlichen Kommentar.

Alle Skills