Der 3-Minuten-Check vor dem Commit: Prüfen, was Claude Code wirklich angefasst hat

An einem Freitagabend bat ich Claude Code: “Ändere nur den Text auf dem Button im Artikel.” Als ich danach git status aufrief, standen dort 18 geänderte Dateien. Eigentlich sollte nur ein Text angepasst werden, doch stattdessen reihten sich die Produktlink-Zuordnung, eingefügte verwandte Artikel und sogar eine Übersetzungsdatei aneinander, die “nebenbei mitkorrigiert” worden war.

Jede einzelne Änderung war “nett gemeint”. Hätte ich aber alles so committet, hätte ich unbemerkt noch ungespeicherte Korrekturen aus einer anderen, parallelen Aufgabe mit hineingezogen und am nächsten Tag beim Deploy einen halben Tag mit einem Fehler verloren, dessen Ursache niemand fand.

Je klüger die KI, desto öfter geht sie ein kleines Stück über den Auftrag hinaus. Nicht aus böser Absicht. Genau deshalb braucht es kurz vor dem Bestätigen diesen einen Moment: “Hier anhalten und mit menschlichem Auge draufschauen.”

Das Wichtigste in Kürze

Claude Code ist treu im Auftrag, doch der Bereich, den es anfasst, weitet sich leise aus. Die Prüfung vor dem Commit ist die Arbeit, dieses “Überschießen” zu finden.
Die Prüfung läuft in drei Minuten nach fester Reihenfolge: Umfang klären, Diff lesen, verifizieren, gezielt die richtigen Dateien stagen. Vier Schritte.
Was du der KI überlässt, ist das “Ausführen der Änderung”. Was der Mensch entscheidet, ist “wie viel davon in diesen Commit gehört”. Diese beiden Dinge nicht vermischen.
Es gibt ein Prüfskript zum Kopieren. Es zeigt git status und eine Zusammenfassung des Diffs auf einem Bildschirm, damit weniger durchrutscht.
Nicht beruhigt sein, nur weil der Build durchläuft. Die Anzeige nach der Veröffentlichung und der Inhalt von Übersetzungen brauchen ein zweites Augenpaar.

Warum die Prüfung genau “kurz vor dem Bestätigen” liegt

Der wirksamste Zeitpunkt ist nicht vor dem Start der Arbeit und auch nicht mittendrin, sondern unmittelbar vor dem Commit. Der Grund ist simpel: Das vollständige Bild der Dateien, die die KI tatsächlich angefasst hat, steht erst genau in diesem Moment fest.

Egal wie oft du vorher sagst “Fass nur das hier an”, die KI greift während der Arbeit zu, sobald sie etwas für “ich korrigiere das besser gleich mit” hält. Hältst du mittendrin an, ist die Arbeit noch nicht abgeschlossen, und du weißt nicht, worauf du schauen sollst. Alles fertig, einen Schritt vor dem Bestätigen: Erst hier lassen sich “das Beauftragte” und “das tatsächlich Geänderte” gegenüberstellen.

Bei mir passieren die meisten Unfälle dort, wo es um Umsatz geht. Verschiebt sich etwa ein einziges Zeichen im Link zur Produktseite, landet die Leserin nach dem Klick auf “Seite nicht gefunden”. Egal wie gut der Text geschrieben ist: Wenn das Linkziel tot ist, endet die Verkaufschance genau dort. Deshalb prüfe ich beim Lesen des Diffs zuerst, ob sich Linkziele verändert haben.

Wer die grundlegende Bedienung von Claude Code noch nicht gefestigt hat, verschafft sich am besten zuerst mit dem Claude Code Einstiegsleitfaden den Überblick. Dann ergibt der Sinn dieser Prüfschritte sofort mehr Sinn.

Die Reihenfolge der Prüfung in drei Minuten

Wenn man es nicht täglich durchhält, bringt es nichts. Deshalb ist der Ablauf auf vier Schritte reduziert. Kein perfektes Audit, sondern eine leichte Sicherung.

Den Umfang laut aussprechen. Wofür war der Auftrag? In einem Satz wiederholen, etwa “Korrektur des Button-Texts im Artikel”. Das wird zum Maßstab für die spätere Entscheidung.
Die Liste der geänderten Dateien ansehen. Mit git status prüfen, welche Dateien sich verändert haben. Liegt etwas außerhalb des einen Satzes, dem du es zugeordnet hast, markiere es im Kopf wie mit einem Klebezettel.
Den Diff der markierten Dateien lesen. Nur in die Dateien außerhalb des Umfangs hineinschauen. Bei nützlichen Änderungen behalten, bei sachfremden Änderungen für diesmal weglassen, jeweils einzeln entscheiden.
Nur die nötigen Dateien gezielt stagen. Nicht mit git add . alles hineinwerfen. Nur die für diesen Auftrag nötigen Dateien namentlich hinzufügen.

Der entscheidende Punkt ist Schritt 3. Mach aus dem von der KI erweiterten Bereich keine Wahl zwischen “alles annehmen” oder “alles ablehnen”. Stück für Stück entscheidet der Mensch, ob etwas bleibt oder rausfliegt. Unscheinbar, aber wer das überspringt, erlebt den 18-Dateien-Unfall vom Anfang.

Was du der KI überlässt und was der Mensch entscheidet

Bleibt diese Grenze unscharf, wird die Prüfung selbst zur reinen Formsache. Ich teile es so auf.

Aufgabe	Zuständig	Grund
Korrekturen an Text oder Code ausführen	KI	großer Umfang, mechanisch erledigbar
Syntaxfehler und offensichtliche Fehler beheben	KI	klare Regeln, leicht automatisierbar
Entscheiden, ob eine Änderung in diesen Commit gehört	Mensch	nur der Mensch kennt die Absicht des Auftrags
Linkziele und Anzeige nach Veröffentlichung prüfen	Mensch	ein durchlaufender Build garantiert keinen Inhalt
Löschen, Produktivdaten, Abrechnung anfassen	Mensch	unumkehrbare Unfälle brauchen menschliche Freigabe

Überlässt du der KI auch noch das “Entscheide du, ob es rein soll”, will die KI selbstverständlich alles einschließen, was sie selbst korrigiert hat. Nur die Entscheidung behältst du in der Hand. Das ist der wichtigste Hebel, um Unfälle zu reduzieren.

Prompt-Vorlage zum Kopieren

Wenn du die KI bei der Prüfung helfen lässt, ist der Trick: Lass sie sich nicht “selbst benoten”, sondern “die Fakten aufreihen”. Die folgende Vorlage kannst du direkt einfügen.

Ich committe gleich. Berichte vor dem Bestätigen bitte nur die folgenden Fakten. Die Entscheidung treffe ich.

1. Fasse den heutigen Auftrag in einem Satz zusammen.
2. Liste mit git status die geänderten Dateien auf (auch nicht getrackte).
3. Davon: welche Dateien scheinen außerhalb dieses einen Satzes zu liegen, und warum?
4. Falls Änderungen Links oder die Anzeige nach Veröffentlichung betreffen könnten, nenne die betroffenen Stellen.

Schreibe nicht "Es gibt keine Probleme". Reihe nur die Entscheidungsgrundlagen auf.

Der letzte Satz wirkt. Ohne ihn fasst die KI gern zufrieden zusammen: “Keine besonderen Probleme, du kannst committen”, und der Sinn der Prüfung verschwindet. Wie man Prompts im Detail aufbaut, habe ich ausführlich in Prompt Engineering für Fortgeschrittene zusammengestellt.

Prüfskript zum Kopieren und Ausführen

Jedes Mal git status und git diff einzeln einzutippen, ist mühsam. Deshalb lege ich hier ein Skript ab, das das Gesamtbild der Änderungen auf einen Bildschirm bringt. Es gibt eine Version für PowerShell und eine für bash. Inhaltlich reiht es nur “die Liste der geänderten Dateien” und “die hinzugefügten bzw. gelöschten Zeilen pro Datei” nebeneinander.

PowerShell-Version (Windows).

# precommit-check.ps1
# Vor dem Commit geaenderte Dateien und Aenderungsumfang auf einem Bildschirm pruefen

Write-Host "=== Diesmal angefasste Dateien ===" -ForegroundColor Cyan
git status --short

Write-Host "`n=== Aenderungsumfang pro Datei (hinzugefuegt / geloescht) ===" -ForegroundColor Cyan
git diff --stat HEAD

Write-Host "`n=== Checkliste zur Pruefung ===" -ForegroundColor Yellow
@(
  "Auftrag in einem Satz nennbar",
  "Keine Dateien ausserhalb des Umfangs dabei",
  "Linkziele und Anzeige nach Veroeffentlichung gesehen",
  "Nur die diesmal noetigen Dateien stagen"
) | ForEach-Object { Write-Host "  [ ] $_" }

bash-Version (macOS / Linux / Git Bash).

#!/usr/bin/env bash
# precommit-check.sh
# Vor dem Commit geaenderte Dateien und Aenderungsumfang auf einem Bildschirm pruefen

echo "=== Diesmal angefasste Dateien ==="
git status --short

echo ""
echo "=== Aenderungsumfang pro Datei (hinzugefuegt / geloescht) ==="
git diff --stat HEAD

echo ""
echo "=== Checkliste zur Pruefung ==="
for item in \
  "Auftrag in einem Satz nennbar" \
  "Keine Dateien ausserhalb des Umfangs dabei" \
  "Linkziele und Anzeige nach Veroeffentlichung gesehen" \
  "Nur die diesmal noetigen Dateien stagen"; do
  echo "  [ ] $item"
done

Die Ausführung ist nur das hier.

bash precommit-check.sh

Dieses Skript entscheidet bewusst nichts automatisch. Damit die Voraussetzung “der Mensch entscheidet” nicht bröckelt, zeigt es absichtlich nur “nebeneinander an”. Sind alle vier Punkte der Checkliste abgehakt, fügst du nur die nötigen Dateien mit git add Dateiname hinzu und committest.

Drei Situationen, in denen es in der Praxis greift

1. Vor der Veröffentlichung von Artikeln oder Unterlagen. Wenn man mehrsprachige Artikel auf einen Schlag veröffentlicht, bleibt manchmal eine Übersetzungsdatei auf Englisch stehen. Der Build läuft durch, aber der Inhalt ist nicht übersetzt. Gib dich nicht damit zufrieden, im Diff nur die Dateinamen zu sehen, sondern prüfe auf der veröffentlichten Seite sogar die Sprache des Fließtexts.

2. Überarbeitung bestehender Dateien. Du wolltest den Text korrigieren, doch dabei wurden auch Links auf der Seite oder Produktnamen umgeschrieben. Wenn du den Umfang vorab in einem Satz auf “Verbesserung des Textes” festlegst, kannst du bei einer Linkänderung als “außerhalb des Umfangs” einmal innehalten.

3. Bei der Einführung im Team. Halte fest, wie weit Claude Code automatisch vorangeht und wo es den Menschen fragt. Betreibt man das mit unklaren Freigaberegeln (welche Operationen automatisch laufen dürfen, welche zwingend nachgefragt werden), entstehen je nach Teammitglied andere Unfallmuster, und es wird unübersichtlich.

Häufige Stolperfallen und wie man sie behebt

Stolperfalle 1: Mit git add . alles hineinwerfen. Das zieht auch ungespeicherte Änderungen einer anderen Aufgabe mit hinein. Die Behebung ist simpel: Statt . die Gewohnheit, Dateien namentlich zu stagen. Auch wenn es mühsam wirkt, ist das die schnellste Versicherung.

Stolperfalle 2: Sich beruhigen, weil der Build durchläuft. Der Build prüft nur die Syntax, nicht ob Linkziele stimmen oder ob Übersetzungen bis in den Inhalt übersetzt sind. Die Behebung: Öffne die veröffentlichte Seite tatsächlich und prüfe Überschrift, Fließtext und Linkziele mit dem Auge. Das Bestehen der Maschine und das Bestehen des Menschen sind zweierlei.

Stolperfalle 3: Die KI “Ist alles okay?” fragen und damit aufhören. Auf Nachfrage neigt die KI dazu, “Alles in Ordnung” zu sagen. Die Behebung: Wie in der Prompt-Vorlage oben anweisen “Schreibe keine Bewertung, reihe nur die Fakten auf”. Gibst du das Subjekt der Entscheidung an den Menschen zurück, beginnt die Prüfung zu funktionieren.

Wie man die Prüfung als Gewohnheit verankert, habe ich auch in Tipps zur Produktivitätssteigerung mit Claude Code zusammengefasst. Das offizielle Verhalten von Git-Optionen wie --stat kannst du in der offiziellen Git-Dokumentation nachschlagen.

Häufige Fragen

F. Mir fehlt die Zeit, jedes Mal drei Minuten zu prüfen. A. An Tagen mit kleinen Änderungen bist du in einer Minute fertig. Drei Minuten brauchst du an Tagen mit vielen Dateien außerhalb des Umfangs, und das sind ohnehin die Tage, an denen Prüfung nötig ist. Sieh die Dauer als Messlatte für die Gefahr.

F. Darf ich der KI auch das Stagen überlassen? A. Bei kleinen Aufgaben, die nachweislich sicher sind, ist das in Ordnung. Ich empfehle aber, allein die letzte Entscheidung “welche Dateien einbezogen werden” beim Menschen zu lassen. Genau hier liegt oft der Einstieg zum Unfall.

F. Was soll in die Commit-Nachricht? A. Zwei Dinge: “was geändert wurde” und “womit geprüft wurde”. Zum Beispiel “Button-Text korrigiert, Linkziel auf der veröffentlichten Seite geprüft”. So sieht man später auf einen Blick, ob geprüft wurde.

F. Was, wenn eine Datei außerhalb des Umfangs eigentlich eine sinnvolle Änderung war? A. Trotzdem lasse ich sie diesmal weg. Sie kommt nur in einen separaten Commit, gelöscht wird nichts. “Eine Absicht pro Commit” zu wahren, macht es später leichter nachzuvollziehen.

Was ich beim Ausprobieren tatsächlich festgestellt habe

Nach dem 18-Dateien-Vorfall vom Anfang schiebe ich diese vier Schritte vor jedem Bestätigen ein. Ausprobiert habe ich drei Muster: Artikelveröffentlichung, Dateiüberarbeitung und Konfigurationsänderung.

Am wirksamsten war der allererste Schritt, “den Auftrag in einem Satz wiederholen”. Allein durch das laute Aussprechen springen mir die Dateien außerhalb des Umfangs ins Auge. Seit ich nach dem Prüfskript aufgehört habe, git add . zu tippen, und stattdessen Dateien namentlich stage, ist die Zahl der Unfälle, bei denen fremde Arbeit mit hineingerät, auf null gesunken.

Überrascht hat mich auch die Wirkung, die Frage an die KI von “Ist alles okay?” auf “Reihe nur die Fakten auf” zu ändern. Dieselbe KI wurde plötzlich zu einem nützlichen Prüfpartner. Statt nach der klügeren KI zu suchen, das Subjekt der Prüfung zum Menschen zurückholen. Das war für mich der unscheinbarste und zugleich wirksamste einzelne Handgriff.

Wenn du Berechtigungsdesign und Prüfungen vor der Veröffentlichung bis in den Teamalltag herunterbrechen willst, baue ich in der Schulung und Beratung das konkrete Design gemeinsam mit dir auf.