MISTAKES.md und Claude Code: Wiederholte Fehler in Regeln verwandeln
Leitfaden für knappe MISTAKES.md-Einträge, Null-Secrets, die Beförderung zu Tests oder Regeln und die Prüfung von Claude-Code-Leitplanken.
Bei komplexen Repositories trifft Claude Code unvermeidlich auf nicht offensichtliche Eigenheiten: veraltete TypeScript-Definitionen, versteckte Laufzeitabhängigkeiten oder bundler-spezifisches Verhalten. Dieselbe Korrektur immer wieder im Chat vorzunehmen verschwendet Kontext und Zeit. Mehrseitige Sitzungsprotokolle in Anweisungen zu kopieren verursacht dagegen Prompt-Müll und schwächere Modellaufmerksamkeit.
Ein praktisches Muster ist eine schlanke MISTAKES.md im Repository-Root. Sie hält nur reproduzierbare Vorfälle, bestätigte Ursachen und Vorbeugungen fest. Anschließend werden sie in Projekttests, Linter-Regeln und dauerhafte Konfiguration überführt.
1. MISTAKES.md statt Sitzungsprotokoll
Verwechseln Sie ein Incident-Log nicht mit einem rohen Terminaltranskript:
MISTAKES.md muss kurz bleiben, damit Claude Code sie zu Sitzungsbeginn einlesen kann, ohne unnötig Context Tokens zu verbrauchen.
2. Aufbau eines Incident-Eintrags
Jeder Eintrag hat vier Pflichtfelder:
- Incident: Was brach unter welchen Bedingungen genau—Fehlercode, Befehl, Tool?
- Impact: Nachgelagerte Wirkung, beispielsweise fehlerhafter Build, beschädigte Migration oder abgebrochene Tests.
- Root Cause: Bestätigte technische Ursache; ist sie unbewiesen, ausdrücklich als
[Hypothesis]markieren. - Prevention: Konkrete Regel oder Prüfung gegen die Wiederholung.
Beispiel für einen Incident-Eintrag
ERR-014: PostgreSQL-Migration bei DROP COLUMN ohne CASCADE fehlgeschlagen
- Incident: Claude Code führte in Migration 0042
ALTER TABLE orders DROP COLUMN customer_ref;aus. - Impact: Das Staging-Deployment scheiterte an der abhängigen View
v_active_orders. - Root Cause: Views, die Basistabellen referenzieren, brauchen eine explizite Neuerstellung mit Cascade oder vorherige View-Updates.
- Prevention: Jede DDL-Migration zum Entfernen einer Spalte muss vor der Ausführung abhängige Views über
pg_dependprüfen.
3. Beförderung vom Log zu Test oder Regel
Nicht jeder einmalige Tippfehler verdient eine permanente Regel. Eine klare Schwelle überführt Einträge in automatisierte Gates:
- Erstes Auftreten: Einen knappen Eintrag in
MISTAKES.mdergänzen. - Zweites Auftreten: Ist das Problem deterministisch prüfbar, Test oder Linter-Regel schreiben. Automatische Gates sind Textprompts überlegen.
- Nicht-mechanische Prüfungen: Eine ausdrückliche negative Regel in
CLAUDE.mdformulieren, etwa „Jest in CI nie ohne --runInBand ausführen“. - Archivierung: Sobald Test oder Hook eingesetzt ist, den Eintrag archivieren oder aus
MISTAKES.mdentfernen, damit die Datei nicht anwächst.
4. Beim nächsten Task verifizieren
So prüfen Sie die neue Leitplanke:
- Eine frische Claude-Code-Sitzung starten.
- Einen Prompt geben, der den früheren Fehler ausgelöst hat.
- Prüfen, ob der Agent die neue Regel einhält oder der Pre-Commit-Hook ihn stoppt.
- Umgeht der Agent Textanweisungen, die Einschränkung in einen strikten Command-Wrapper oder eine automatische Prüfung überführen.
Diese Rückkopplung verwandelt zufällige Entwicklungsfehler in eine robuste, sich selbst verbessernde Engineering-Grundlage.