Prompt-to-PR Workflow mit Claude Code: Kleine Diffs

Warum Prompt‑to‑PR bessere Ergebnisse als große One‑Shot‑Prompts liefert

Große One‑Shot‑Prompts führen oft zu umfangreichen, unübersichtlichen Änderungen: dutzende Dateien berührt, unzusammenhängende Refactors und Code, den du nicht in Ruhe verstanden hast. Selbst wenn das Ergebnis technisch korrekt ist, fühlt sich das Review riskant an, weil schwer nachvollziehbar ist, was sich geändert hat und warum.

Kleine Diffs verhindern das. Wenn jede Änderung begrenzt und fokussiert ist, kannst du sie in Minuten lesen, Fehler früh erkennen und vermeiden, unbeabsichtigt Dinge zu brechen. Reviewer vertrauen kleinen PRs mehr, weshalb Merges schneller und mit weniger Rückfragen passieren.

Prompt‑to‑PR ist eine einfache Schleife:

• Bitte um eine einzelne, kleine Änderung mit klaren Grenzen.
• Prüfe den Diff und bestätige, dass er der Absicht entspricht.
• Führe deine üblichen Checks aus (Tests, Lint, Build).
• Wenn etwas fehlschlägt, re‑prompt mit der genauen Fehlermeldung und dem Kontext.
• Wiederhole, bis es merge‑bereit ist.

Dieses Tempo verwandelt Fehler in schnelles Feedback statt in eine Überraschung am Ende. Wenn du Claude Code bittest, eine Validierungsregel anzupassen, beschränke dich genau auf diese eine Regel. Wenn ein Test fehlschlägt, füge die fehlschlagende Ausgabe ein und bitte um die kleinste Änderung, die den Test bestehen lässt — nicht um ein komplettes Umstellen des Moduls.

Eines ändert sich nicht: Du bist weiterhin verantwortlich für den finalen Code. Behandle das Modell wie einen lokalen Pair‑Programmierer, der schnell tippt, nicht wie einen Autopiloten. Du entscheidest, was rein darf, was draußen bleibt und wann es sicher ist, den PR zu öffnen.

Bereite dein Repo und dein lokales Pairing‑Setup vor

Starte von einer sauberen Basis. Wenn dein Branch veraltet ist oder Tests bereits fehlschlagen, wird jede Vorschlag zu Rätselraten. Pull die neuesten Änderungen, rebase oder merge wie dein Team es bevorzugt und stelle sicher, dass der aktuelle Zustand gesund ist, bevor du etwas anfragst.

Ein „lokales Pair‑Programmierer“‑Setup bedeutet, dass Claude Code Dateien in deinem Repo editiert, während du die Kontrolle über Ziel, Guardrails und jeden Diff behältst. Das Modell kennt deinen Code nicht, wenn du ihn nicht zeigst, also sei explizit über Dateien, Einschränkungen und erwartetes Verhalten.

Bevor du den ersten Prompt sendest, entscheide, wo die Checks laufen. Wenn du Tests lokal ausführen kannst, bekommst du Feedback in Minuten, was die Iterationen klein hält. Wenn einige Checks nur in CI laufen (bestimmte Lint‑Regeln, lange Suites, Build‑Schritte), lege fest, wann du dich auf CI verlässt, damit du nicht nach jeder kleinen Änderung warten musst.

Eine einfache Pre‑Flight‑Liste:

• Aktualisiere deinen Branch und bestätige, dass die App buildet oder startet.
• Führe die schnellen Checks lokal aus (Lint, Unit‑Tests, Typecheck).
• Notiere, welche Checks CI‑only sind und wie lange sie üblicherweise dauern.
• Bestätige, dass du das Problem reproduzieren oder das fehlende Feature klar sehen kannst.
• Sorge dafür, dass du Änderungen leicht rückgängig machen kannst (sauberer Status, kleine Commits).

Halte einen kleinen Scratchpad offen, während du arbeitest. Schreibe Einschränkungen wie „no API changes“, „bei‑wärtskompatibel bleiben“, „nur Modul X anfassen“ sowie Entscheidungen, die du triffst. Wenn ein Test fehlschlägt, füge dort auch die exakte Fehlermeldung ein. Dieses Scratchpad wird die beste Eingabe für deinen nächsten Prompt und verhindert, dass die Session abschweift.

Schreibe Prompts, die natürlich zu kleinen Diffs führen

Kleine Diffs beginnen mit einem absichtlich engen Prompt. Der schnellste Weg zu mergebarem Code ist eine Änderung, die du in einer Minute prüfen kannst — nicht ein Refactor, den du eine Stunde verstehen musst.

Ein guter Prompt benennt ein Ziel, einen Bereich des Codes und ein erwartetes Ergebnis. Wenn du nicht angeben kannst, wo die Änderung landen soll (Datei, Ordner oder Modul), wird das Modell raten und der Diff wuchert.

Eine Prompt‑Form, die Änderungen eng hält:

• Ziel: das einzelne Verhalten, das du ändern willst.
• Ort: die Datei(en) oder Komponente, die berührt werden sollen.
• Einschränkungen: was nicht geändert werden darf.
• Akzeptanz: wie „fertig“ aussieht.
• Diff‑Größe: fordere explizit die kleinste mögliche Änderung an.

Grenzen sind die Geheimwaffe. Statt „fix the login bug“ sage, was bestehen bleiben muss: „API‑Shape nicht ändern“, „öffentliche Funktionen nicht umbenennen“, „keine rein formatierenden Edits“, „neue Dependencies vermeiden“. Das sagt deinem Pair‑Programmierer, wo er nicht kreativ werden soll.

Wenn die Änderung noch unklar wirkt, bitte zuerst um einen Plan statt um Code. Ein kurzer Plan zwingt die Arbeit in Schritte und gibt dir die Chance, einen kleinen ersten Schritt freizugeben.

Goal: Fix the null crash when rendering the profile header.
Location: src/components/ProfileHeader.tsx only.
Constraints: Do not change styling, props, or any exported types.
Expected outcome: If user.name is missing, show "Anonymous" and no crash.
Diff constraint: Minimal diff. No refactors. No unrelated formatting.
If unclear: First reply with a 3-step plan, then wait for approval.

Wenn du im Team arbeitest, füge Review‑Constraints hinzu: „Halte es unter ~30 geänderten Zeilen“ oder „Nur eine Datei, außer es ist absolut nötig.“ Das macht den Diff leichter zu scannen und verschärft Follow‑up‑Prompts, wenn etwas fehlschlägt.

Wähle die richtige Arbeitseinheit für jede Iteration

Halte jede Schleife auf eine kleine, testbare Änderung fokussiert. Wenn du das Ziel in einem Satz beschreiben kannst und vorhersagen kannst, welche Dateien sich ändern, ist die Größe passend.

Gute Arbeitseinheiten sind: einen Bug in einem Pfad beheben (mit Repro und Guard), einen einzelnen Test für ein Verhalten anpassen, einen verhaltensneutralen Refactor (Umbenennen, Funktion extrahieren, Duplikate entfernen) oder eine Fehlermeldung/Validierung verbessern.

Setze eine Zeitbox pro Loop. 10–20 Minuten sind meist genug, um einen klaren Prompt zu schreiben, den Diff anzuwenden und einen schnellen Check auszuführen. Wenn du nach 20 Minuten noch am Erkunden bist, verkleinere die Einheit oder wechsle zu reiner Untersuchung (Notizen, Logging, fehlschlagender Test) und stopp.

Definiere „done“ bevor du startest:

• Die Änderung bleibt innerhalb der vorgesehenen Dateien und des Verhaltens.
• Ein Check beweist, dass es funktioniert (Test, Lint oder ein einfacher Lauf).
• Keine neuen Warnungen oder laute Formatierungsänderungen.
• Der Diff lässt sich in zwei Sätzen erklären.

Wenn der Umfang wächst, stopp früh. Wenn du dich dabei erwischst „while we are here“ zu sagen, hast du gerade die nächste Iteration gefunden. Notiere sie als Follow‑up, commite den aktuellen kleinen Diff und mach weiter.

Review den Diff bevor du Checks ausführst

Bevor du Tests oder Builds startest, lies den Diff wie ein Reviewer. Hier bleibt der Workflow sauber oder driftet stillschweigend in „Warum hat es diese Datei berührt?“‑Territorium.

Bitte Claude Code zuerst um eine Zusammenfassung der Änderungen in Klartext: berührte Dateien, Verhaltensänderung und was nicht verändert wurde. Wenn es die Änderung nicht klar erklären kann, macht der Diff wahrscheinlich zu viel.

Dann reviewe selbst. Überfliege zuerst den Scope, lies dann auf Intent. Du suchst nach Drift: unzusammenhängende Formatierung, zusätzliche Refactors, umbenannte Symbole oder nicht angeforderte Änderungen.

Eine kurze Vorprüfung:

• Stimmen die geänderten Dateien mit deiner Anfrage überein?
• Gibt es Drive‑By‑Edits (Whitespace‑Churn, unzusammenhängende Refactors)?
• Wurde neues Verhalten eingeführt, das du nicht angefordert hast?
• Gibt es eine neue Abhängigkeit oder Konfig‑Änderung, die einen echten Grund braucht?
• Kann ein Reviewer das verstehen, ohne fünf andere Dateien zu lesen?

Wenn der Diff größer als erwartet ist, versuche nicht, dich durch Tests rauszuwinden. Roll zurück und re‑prompt für einen kleineren Schritt. Zum Beispiel: „Füge nur einen fehlschlagenden Test hinzu, der den Bug reproduziert. Keine Refactors.“ Kleine Diffs machen Fehler leichter interpretierbar und schärfen den nächsten Prompt.

Führe nach jeder kleinen Änderung Checks aus

Kleine Diffs zahlen sich nur aus, wenn du sie sofort verifizierst. Ziel ist eine enge Schleife: wenig ändern, wenig prüfen, Fehler finden, solange der Kontext frisch ist.

Starte mit dem schnellsten Check, der dir sagen kann „das ist kaputt“. Hast du Formatierung oder Imports geändert, starte mit Lint/Format. Bei Business‑Logic‑Änderungen führe die kleinsten Unit‑Tests für die betroffene Datei/Package aus. Bei Typen‑ oder Build‑Änderungen kompiliere kurz.

Eine praktische Reihenfolge:

• Lint oder Format.
• Zielgerichtete Unit‑Tests für den Bereich, den du geändert hast.
• Build oder Typecheck, um sicherzustellen, dass alles zusammenpasst.
• Langsamere Suites (Integration, End‑to‑End) erst, wenn die Basics laufen.

Wenn etwas fehlschlägt, dokumentiere zwei Dinge, bevor du etwas änderst: den genauen Befehl, den du ausgeführt hast, und die vollständige Fehlerausgabe (kopiert wie sie ist). Dieses Protokoll macht den nächsten Prompt spezifisch und verhindert „es schlägt immer noch fehl“‑Loops.

Halte den Umfang eng. Wenn Lint und Tests fehlschlagen, behebe zuerst Lint, führe es erneut aus und kümmere dich dann um die Tests. Mische nicht „schnelle Aufräumarbeiten“ mit einem Crash‑Fix im selben Durchgang.

Re‑prompt mit Fehlerausgaben, bis die Checks grün sind

Wenn Checks fehlschlagen, behandel die Fehlermeldung als deinen nächsten Prompt. Die schnellste Schleife ist: Fehler einfügen, Diagnose bekommen, minimale Korrektur anwenden, erneut ausführen.

Füge Fehler wortwörtlich ein, inklusive Befehl und vollständigem Stacktrace. Bitte zuerst um die wahrscheinlichste Ursache, nicht um ein Menü von Optionen. Claude Code arbeitet besser, wenn es sich an exakten Zeilennummern und Meldungen orientieren kann, statt zu raten.

Füge einen Satz hinzu, was du schon versucht hast, damit es nicht im Kreis läuft. Wiederhole Einschränkungen, die wichtig sind („öffentliche APIs nicht ändern“, „aktuelles Verhalten beibehalten, nur den Crash beheben“). Fordere dann den kleinsten Patch an, der die Prüfung bestehen lässt.

Ein guter Failure‑Prompt enthält:

• Die exakt fehlschlagende Ausgabe (wortwörtlich).
• Die beteiligten Datei(en) und Zeilen.
• Was du im letzten Diff geändert hast.
• Was du bereits versucht hast.
• Die Bitte um den kleinsten Patch, der den Check bestehen lässt.

Wenn der vorgeschlagene Fix Verhalten ändert, fordere einen Test an, der das neue Verhalten beweist. Wenn ein Handler jetzt 400 statt 500 zurückgibt, bitte um einen fokussierten Test, der im alten Code scheitert und mit dem Fix besteht. Das hält die Arbeit ehrlich und macht den PR vertrauenswürdiger.

Stoppe, sobald die Checks grün sind und der Diff weiterhin nur eine Idee enthält. Wenn das Modell anfängt, unzusammenhängenden Code zu verbessern, re‑prompt mit: „Nur den fehlschlagenden Test adressieren. Kein Cleanup.“

Mache den PR leicht zu reviewen und zu mergen

Ein PR wird am schnellsten gemerged, wenn klar ist, was sich geändert hat, warum und wie man es prüft. In diesem Workflow sollte der PR wie eine kurze Geschichte lesbar sein: kleine Schritte, klare Gründe.

Halte Commits in Übereinstimmung mit deinen Iterationen. Hast du um eine Verhaltensänderung gebeten, mach dazu einen Commit. Hast du danach einen fehlschlagenden Test behoben, mach das zum nächsten Commit. Reviewer können so den Weg nachverfolgen und sind sicher, dass du nichts Einschleichendes gemacht hast.

Schreibe Commit‑Messages auf Intent, nicht Dateinamen. „Fix login redirect when session expires“ ist besser als „Update auth middleware“. Wenn die Nachricht das nutzerseitige Ergebnis benennt, raten Reviewer weniger.

Vermeide, Refactors mit Verhaltensänderungen im selben Commit zu mischen. Wenn du Variablen umbenennen oder Helfer verschieben willst, mach das separat (oder lass es vorerst). Rauschen verlangsamt das Review.

In der PR‑Beschreibung kurz und konkret:

• Was sich geändert hat (1–2 Sätze).
• Warum es geändert wurde (der Bug oder Requirement).
• Wie zu testen ist (exakte Schritte, inklusive Flags oder benötigter Daten).
• Was du nicht geändert hast (setzt Erwartungen).
• Risiko‑ oder Rollback‑Hinweis.

Beispiel: Eine Billing‑Seite stürzt ab, weil ein Kunde keinen Profil‑Datensatz hat. Commit 1 fügt eine Guard‑Abfrage und eine klare Fehlerdarstellung hinzu. Commit 2 fügt einen Test für den Null‑Fall hinzu. Die PR‑Beschreibung lautet: „Öffne Billing, lade einen Kunden ohne Profil, bestätige, dass die Seite den neuen Empty‑State zeigt.“ So kann ein Reviewer schnell zustimmen.

Häufige Fallen, die dich ausbremsen

Das Tempo bricht zusammen, wenn der Scope stillschweigend wächst. Ein Prompt, der als „fix this failing test“ beginnt, wird zu „Verbessere Error‑Handling im ganzen Modul“ – plötzlich prüfst du einen großen Diff mit unklarer Absicht. Halte es eng: ein Ziel, ein Änderungssatz, ein Set an Checks.

Ein weiteres Hindernis ist, hübsche Refactors einfach zu akzeptieren, nur weil sie gut aussehen. Umbenennungen, Dateiverschiebungen und Style‑Änderungen erzeugen Rauschen im Review und machen es schwerer, die echte Verhaltensänderung zu erkennen.

Häufige Fallen:

• Das Modell lässt sich erlauben, unrelated Dateien zu ändern „weil es gerade hier ist“.
• Symptome fixen (zusätzliche Null‑Checks) statt der Root‑Cause, auf die der Test hinweist.
• Nur die letzten Zeilen eines Logs einfügen und den ersten Fehler verbergen.
• Überspringen eines schnellen Diff‑Scans vor dem Ausführen von Checks.
• Re‑prompten mit „es schlägt immer noch fehl“ statt mit dem genauen Befehl und der Ausgabe.

Ein konkretes Beispiel: Ein Test sagt „expected 400, got 500.“ Wenn du nur den Tail des Stacktraces einfügst, bekommst du oft generische Try/Catch‑Vorschläge. Wenn du die komplette Testausgabe einfügst, siehst du vielleicht die eigentliche Ursache: ein fehlender Validierungszweig. Das führt zu einem kleinen, fokussierten Diff.

Bevor du committest, lies den Diff wie ein Reviewer. Frag dich: Dient jede Zeile der Anfrage, und kann ich das in einem Satz erklären? Wenn nicht, revertiere die Extra‑Änderungen und re‑prompt mit einer schmaleren Aufgabe.

Beispiel: Bugfix zu mergebarem PR in wenigen Loops

Ein Nutzer meldet: „Die Einstellungen‑Seite setzt sich manchmal nach dem Speichern auf Defaults zurück.“ Du ziehst main, führst Tests aus und siehst einen Fehler. Oder es gibt keine Tests, nur ein klares Reproduktionsszenario.

Behandle es als Schleife: eine kleine Anfrage, ein kleiner Diff, dann Checks.

Zuerst gib Claude Code den kleinsten nützlichen Kontext: fehlschlagende Testausgabe (oder Repro‑Schritte), den Datei‑Pfad, den du vermutest, und das Ziel („Verhalten bleibt gleich außer das Reset wird behoben“). Bitte um eine Diagnose und einen minimalen Patch, nicht um einen Refactor.

Dann arbeite in kurzen Loops:

1. Loop 1 (minimaler Patch): Wende die kleinste Änderung an, die plausibel den Bug behebt. Halte es eng: eine Guard‑Abfrage, ein fehlender Null‑Check, ein falscher Default‑Wert oder eine falsche Dependency‑Liste.

Führe nach Review des Diffs Checks aus.

2. Loop 2 (genaue Fehlermeldung zurückfüttern): Falls Tests fehlschlagen, kopiere die exakte fehlschlagende Ausgabe zurück zu Claude Code. Schließe Dateiname, Zeilennummer und Assertion‑Message ein. Frage: „Was ist die kleinste Änderung, um diesen Fehler zu beheben, ohne den Scope zu erweitern?“

Wenn die Checks grün sind, du aber Regressionen fürchtest, füge Coverage hinzu.

3. Loop 3 (Test anpassen oder neuen Test hinzufügen): Füge einen Test hinzu, der ohne Patch fehlschlägt und mit Patch besteht. Halte ihn fokussiert. Führe Checks erneut aus.

Zum Abschluss eine kurze PR‑Beschreibung: was der Bug war, warum er auftrat und was geändert wurde. Füge eine Hinweiszeile für Reviewer hinzu wie „berührt nur X Datei“ oder „ein Test für den Reset‑Fall hinzugefügt“, damit das Review sicher wirkt.

Schnelle Checkliste bevor du den PR öffnest

Unmittelbar bevor du einen Pull Request öffnest, mach eine letzte Runde, damit die Arbeit leicht zu reviewen und sicher zu mergen ist.

• Der Diff entspricht dem ursprünglichen Ziel und ist klein genug, um ihn in wenigen Minuten zu verstehen.
• Du hast die relevanten Checks (Tests, Lint, Typecheck, Build) ausgeführt und sie laufen. Wenn dein Team CI nutzt, bestätige, dass dieselben Checks dort laufen.
• Die Änderung hat das richtige Sicherheitsnetz: wenn praktikabel, ein Test für den Bug oder Feature, oder ein klarer Grund, warum kein Test nötig ist.
• Die PR‑Beschreibung ist spezifisch: was geändert wurde, warum und exakte Schritte zur Verifikation.
• Es gibt keine Drive‑By‑Edits: keine unrelated Formatierung, style‑only Umbenennungen oder unnötige Refactors.

Ein kurzes Beispiel: Wenn du einen Login‑Bug behoben, aber gleichzeitig 20 Dateien reformatiert hast, zieh die Formatierungs‑Commits zurück. Dein Reviewer soll sich auf den Login‑Fix konzentrieren, nicht darauf rätseln, was sonst noch verschoben wurde.

Wenn ein Punkt nicht passt, mach noch einen kleinen Loop: eine winzige Änderung, Checks erneut laufen lassen und die PR‑Notizen aktualisieren. Diese letzte Runde spart oft Stunden an Hin‑und‑Her.

Nächste Schritte: Mach dieses Tempo zur Gewohnheit

Konsistenz verwandelt eine gute Session in einen verlässlichen Workflow. Wähle eine Standard‑Schleife und führe sie jedes Mal gleich aus. Nach einer Woche merkst du, dass deine Prompts kürzer werden und deine Diffs leichter zu reviewen sind.

Eine einfache Routine:

• Wähle ein winziges Ergebnis (einen Bug, einen Edge‑Case, eine Funktion).
• Bitte um einen kleinen Diff und eine kurze Erklärung, was sich geändert hat.
• Lies den Diff wie ein Reviewer, dann führe lokale Checks aus.
• Re‑prompt mit der exakten Fehlermeldung und Datei‑Namen.
• Stoppe, sobald die Checks grün sind und die Änderung klar ist.

Eine persönliche Prompt‑Vorlage hilft, diszipliniert zu bleiben: „Ändere nur, was nötig ist. Berühre höchstens 2 Dateien. Behalte öffentliches Verhalten bei, sofern ich nichts anderes sage. Sag mir den Befehl, den ich ausführen soll, und wie Erfolg aussieht.“

Wenn du in Koder.ai arbeitest, kannst du dieselbe Schleife in der Chat‑Schnittstelle nutzen. Planning Mode eignet sich gut, um den kleinstmöglichen mergebaren Slice zu scopen (Inputs, Outputs und Akzeptanzchecks), und Snapshots & Rollback helfen dir, schnell wiederherzustellen, wenn ein Experiment schiefgeht.

Sobald die Änderung stabil ist, exportiere den Source Code, um deine üblichen lokalen Tools, CI und Team‑Reviews im normalen Repo laufen zu lassen. Deploye, wenn du echte End‑to‑End‑Validierung brauchst, z. B. um einen Flow vollständig zu testen.

Mach die Schleife zu deiner Default‑Arbeitsweise. Kleine Prompts, kleine Diffs, häufige Checks und schnelle Korrekturen ergeben zusammen PRs, die im besten Sinne langweilig sind.