Ein praktisches Handbuch zur Erstellung eines effektiven CLAUDE.md-Files
Lernen Sie 21 konkrete, überprüfbare Regeln zum Kürzen eines überdimensionierten CLAUDE.md-Files, damit Claude Code in langen Sitzungen zuverlässig, vorhersehbar und vertrauenswürdig bleibt.
Vor einem Monat entfernte ein Entwickler 340 Zeilen aus einer CLAUDE.md-Datei, die sich bereits ein Jahr lang weiterentwickelt hatte.
Die Datei wuchs stetig an. Jedes Mal, wenn Claude Code etwas Störendes tat, wurde eine neue Regel hinzugefügt. Jedes Mal, wenn eine Regel nicht funktionierte, wurde eine längere Version darunter angehängt. Bis August umfasste die Datei 400 Zeilen, und Claudes Verhalten war deutlich schlechter als zu dem Zeitpunkt, als die Datei noch aus nur 60 Zeilen bestand.
Nachdem die Anzahl der Zeilen auf 61 reduziert worden war, zeigte sich die Verbesserung bereits am selben Tag.
Das ist eigentlich keine Lektion über persönliche Disziplin. Es handelt sich vielmehr um eine Lektion darüber, wofür eine Regeldatei dient. Sie ist keine Wunschliste, die im Laufe der Zeit angehäuft wird. Vielmehr handelt es sich um eine Reihe von Anweisungen, die das Modell zu Beginn jeder Sitzung liest – und jede zusätzliche Zeile muss um Aufmerksamkeit mit allem anderen konkurrieren, was bereits darin enthalten ist.
Im Folgenden finden Sie die 21 Regeln, die die Auswahl bestanden haben, zusammen mit der Begründung für jede von ihnen.
Die tatsächlichen Kosten eines überdimensionierten CLAUDE.md
Im August 2026 beschloss jemand in der Claude Code-Community, etwas zu testen, das auf den ersten Blick offensichtlich erscheint, aber noch von niemandem wirklich überprüft wurde: ob Claude tatsächlich den in CLAUDE.md gegebenen Anweisungen folgt.
Bei einer ersten Überprüfung stellte sich heraus, dass 55,7 % der Regeln in einer typischen Datei grundsätzlich überhaupt überprüft werden konnten. Eine manuelle Überprüfung senkte diese Zahl auf 18 %, anschließend auf 8,75 %, bis sie schließlich bei 6,67 % lag.
Bleiben Sie einen Moment bei dieser Zahl. In einem typischen CLAUDE.md kann tatsächlich nur etwa eine Regel von fünfzehn überprüft werden. Die verbleibenden vierzehn sind im Grunde nur allgemeine Empfehlungen wie „schreiben Sie sauberen Code“, „befolgen Sie die besten Praktiken“ oder „seien Sie vorsichtig mit der Leistung“. Niemand – weder das Modell noch Sie – kann feststellen, ob diese tatsächlich befolgt wurden.
Das ist die wahre Kostenfalle eines überdimensionierten Files. Es geht nicht nur darum, dass unüberprüfbare Regeln ignoriert werden. Vielmehr nehmen sie in jedem Schritt weiterhin Platz im Kontextfenster ein und verdrängen damit die Regeln, die tatsächlich von Bedeutung gewesen wären.
Ungefähr zur gleichen Zeit machten Anthropics eigene Ingenieure eine ähnliche Beobachtung bezüglich der Systemanweisungen für ihr System: Ab einer bestimmten Länge verschlechtert das Hinzufügen weiterer Anweisungen die Leistung anstelle, sie zu verbessern. Ihre neuesten Modelle werden nun mit Systemanweisungen ausgeliefert, die nur noch einen Bruchteil der ursprünglichen Größe haben.
Ihre CLAUDE.md-Datei folgt genau dem gleichen Muster. Die 21 unten aufgeführten Regeln dienen dazu, sich auf der produktiven Seite dieser Kurve zu halten.
Regeln 1–7: Schaden vermeiden
Diese ersten Regeln dienen dazu, zu verhindern, dass Claude eine einfache Aufgabe in ein Desaster verwandelt.
Regel 1: Führen nur präzise Änderungen durch
## Editing
Change the minimum number of lines needed.
Do not reformat, reorder, or rename anything you were not asked to change.
Match the style already in the file, even if you would write it differently.
Warum es funktioniert: Ohne diese Einschränkung neigt Claude dazu, jede Datei, die er bearbeitet, „zu verbessern“. Man bittet um eine einzeilige Korrektur und muss am Ende einen 200 Zeilen langen Diff durchgehen, wobei die eigentliche Korrektur irgendwo darin versteckt ist. Das ist wohl der häufigste Kritikpunkt an Programmier-Assistenten – und zugleich einer der einfachsten zu lösenden.
Vorher: Man bittet um eine Korrektur für einen Off-by-One-Fehler in einer Callback-Funktion. Stattdessen wird der Code in async/await umgewandelt, drei Variablen umbenannt – und der ursprüngliche Fehler bleibt bestehen.
Nachher: Nur eine einzige Zeile ändert sich. Die Überprüfung dauert etwa vier Sekunden.
Regel 2: Schreibt niemals meine Tests um
## Tests
Do not edit existing tests to make failing code pass.
If a test fails, fix the code.
If you believe the test itself is wrong, say so and stop. Do not edit it.
Warum es funktioniert: Ein Modell, dem befohlen wird, Tests bestehen zu lassen, wählt stets den kürzesten verfügbaren Weg – und das Umschreiben einer Assertion ist kürzer als die tatsächliche Behebung des zugrunde liegenden Fehlers. Diese Regel beseitigt diesen Kurzweg völlig.
Vorher: Drei Tests werden grün. Zwei von ihnen überprüfen nun etwas Falsches.
Nachher: Claude meldet, dass ein Test mit 404 rechnet, während der Code 500 zurückgibt, und fragt anschließend, welcher Test tatsächlich falsch ist.
Regel 3: Fügen Sie keine Abhängigkeit hinzu
## Dependencies
Do not add packages. Use what is already in package.json.
If you are convinced a new package is needed, name it, name what it
replaces, and stop. Wait for approval.
Warum es funktioniert: Jeder Programmier-Assistent greift auf neue Bibliotheken genauso zu wie ein Junior-Entwickler. Wenn man das unkontrolliert lässt, entstehen drei separate Pakete zur Datumsbearbeitung sowie eine Dateigröße, die niemand erklären kann.
Früher: Eine einfache Aufgabe zur Formatierung eines Datums in vier Zeilen führt zu einer neuen Abhängigkeit sowie zu einer Änderung des Lockfiles.
Nachher: Dieselben vier Zeilen, erstellt mithilfe der bereits verfügbaren Intl-API.
Regel 4: Keine Fehlerbehandlung für Dinge, die nicht auftreten können
## Error Handling
Handle errors that can actually occur here.
Do not add try/catch around code that cannot throw.
Do not add null checks for values this function is guaranteed to receive.
Warum es funktioniert: Defensiver Code, der gegen unmögliche Zustände schützen soll, ist eigentlich keine Sicherheitsmaßnahme, sondern nur Ballast. Er versteckt die beiden wirklich wichtigen Überprüfungen und verdoppelt den Umfang einer Funktion ohne Nutzen.
Früher: Eine 12 Zeilen lange Funktion, die mit vier Schutzklauseln aufgefüllt ist, von denen drei niemals ausgelöst werden können.
Nachher: Dieselbe 12 Zeilen lange Funktion, die nur noch die eine Überprüfung beibehält, die tatsächlich fehlschlagen könnte.
Regel 5: Berühren Sie nicht das, um das Sie nicht gebeten wurden
## Scope
Work only on what was asked.
Unrelated dead code, bad names, or missing types: mention them, do not fix them.
Remove imports and variables that YOUR change made unused. Nothing else.
Warum es funktioniert: Ein Scope-Creek, der innerhalb eines Diffs verborgen ist, bleibt unsichtbar, bis jemand ihn überprüft – und bis dahin wird bereits wertvolle Zeit verschwendet. Wenn die Grenzen von vornherein klar definiert werden, entfällt das Rätseln darüber, was als zulässig gilt.
Regel 6: Vertrauliche Informationen niemals speichern
## Security
Never write a key, token, password, or connection string into a file.
Never commit .env, .env.*, or any credentials file.
If a value is needed, reference the environment variable by name.
Warum es funktioniert: Dies ist einer der seltenen Fälle, in denen ein einziger Fehler nicht mehr rückgängig gemacht werden kann. Die Anweisung ist kurz, bedingungslos und leicht zu überprüfen – genau das sollte eine gute Regel haben.
Regel 7: Bevor etwas Zerstörerisches unternommen wird, fragen
## Destructive Actions
Stop and ask before: dropping a table, deleting a branch, force pushing,
rewriting history, deleting a file you did not create, or running a
migration against anything that is not local.
Warum es funktioniert: Ein Modell verfügt nicht über ein eingebautes Verständnis dafür, was rückgängig gemacht werden kann und was nicht. Aus seiner Sicht sind das Überschreiben der Historie sowie das Formatieren einer Textdatei derselbe Vorgang – einfach nur ein weiterer Aufruf eines Tools. Diese Regel gibt ihm eine Risikokategorie, die es sonst nicht selbst erkennen könnte.
Regeln 8–14: Schreiben Sie Regeln, die tatsächlich befolgt werden können
Dieser Abschnitt befasst sich mit dem zugrunde liegenden Problem hinter der niedrigen Konformitätsrate. Diese Regeln betreffen nicht direkt das Verhalten, sondern vielmehr die Formulierung der Regeln, die dieses Verhalten steuern.
Regel 8: Jede Regel muss überprüfbar sein
Bad: Write clean, maintainable code.
Good: Functions over 40 lines must be split.
Warum es funktioniert: Wenn man den Ausgabeinhalt nicht einmal kurz betrachten und mit Ja oder Nein antworten kann, bewirkt die Regel nichts anderes, als Platz im Kontext zu beanspruchen. Bevor man eine Zeile in dieses File einfügt, sollte man sich fragen, welche Beweise zeigen würden, dass die Regel verletzt wurde. Wenn man darauf keine Antwort hat, sollte man die Regel nicht hinzufügen.
Vorher: Eine Anweisung wie „Schreibe sauberen, wartbaren Code“ liegt monatelang ungenutzt im File. Sie beeinflusst niemals die Ausgabe, und man kann nie auf einen Fall verweisen, in dem sie missachtet wurde.
Nachher: Eine 61 Zeilen lange Funktion erscheint im Diff, und man kann direkt auf die Regel verweisen, die sie verletzt. Danach wird entweder die Regel eingehalten oder entfernt – beides bringt die Dinge voran.
Regel 9: Eine Regel, eine Zeile
Bad: When you are working on components, please try to keep them
focused and reasonably small, and generally avoid mixing data
fetching with presentation where that makes sense.
Good: Components do not fetch data. Fetch in the route, pass props down.
Warum es funktioniert: Eine Regel, die in vagen Formulierungen versteckt ist, wirkt wie ein sanfter Vorschlag. Vorschläge werden stets von dem übertroffen, wozu das Modell ohnehin neigt.
Regel 10: Nennen Sie die Datei, nicht das Gefühl
Bad: Follow our API conventions.
Good: New routes follow the shape in src/api/users/route.ts.
Warum es funktioniert: Ein Ausdruck wie „unsere Konventionen“ bedeutet nur etwas für Sie als Mensch. Ein Dateipfad hingegen ist etwas, das das Modell tatsächlich öffnen und lesen kann. Auf echten, vorhandenen Code zu verweisen ist besser als jede Menge Prosa, die diesen Code beschreibt.
Regel 11: Verbieten statt ermutigen
Bad: Prefer simple solutions.
Good: Do not add an interface with one implementation.
Do not add a config option for a value that never changes.
Warum es funktioniert: Wörter wie „prefer“ wirken nur als Entscheidungshilfe und ausschließlich dann, wenn das Modell bereits unsicher ist. „Do not“ hingegen fungiert als strikter Stopp. Fast jede Regel, die in der Praxis versagt, versagt deshalb, weil sie als Ermutigung statt als Verbotsregel formuliert wurde.
Es gibt einen einfachen Test dafür: Lesen Sie die Regel und fragen Sie sich, ob ein Modell, das dazu neigt, das zu tun, was Sie verhindern möchten, die Regel dennoch technisch gesehen befolgen könnte. Wenn ja, handelt es sich bei dem Geschriebenen um eine Präferenz und nicht um eine Regel.
Regel 12: Platziere die Regel dort, wo die Arbeit stattfindet
Core rules live in the root CLAUDE.md, not only in path-scoped rule files.
Warum es funktioniert: Dieser Punkt wird leicht übersehen und kann zu ernsthaften Fehlern führen, wenn man ihn ignoriert. Im August 2026 wurde ein Problem bezüglich Claude Code gemeldet, in dem beschrieben wurde, wie regelbasierte Dateien mit Pfadbeschränkung stillschweigend fehlschlagen können, wenn der Agent Dateien über Shell-Befehle statt über sein integriertes Bearbeitungstool ändert – schließlich ist die Einbindung von Regeln an diesen Bearbeitungsweg gebunden. Andere Nutzer berichteten vom gleichen Problem bei Regeln, die in verschachtelten Unterordnerdateien gespeichert sind.
Diese Lektion gilt unabhängig davon, ob dieser spezielle Fehler behoben wird. Alles, was man auf keinen Fall auslassen darf, muss in der Wurzeldatei enthalten sein, die immer geladen wird – und nicht in einer bedingten Datei, die nur manchmal geladen wird.
Regel 13: Begrenzung der Dateilänge
CLAUDE.md stays under 60 lines. If you need line 61, delete something first.
Warum es funktioniert: Dies ist die Regel, die die tatsächliche Struktur eines Teams am meisten verbessert hat – und sie widerspricht dem gesunden Menschenverstand. Wenn eine Datei auf 400 Zeilen erweitert wird, bedeutet das nicht automatisch, dass es 400 Regeln gibt, auf die das Modell reagieren kann. Es entsteht lediglich ein dichter Textblock, in dem die wichtigen Anweisungen mit dem Überflussmaterial verschmelzen.
60 Zeilen sind kein magischer Schwellenwert. Entscheidend ist vielmehr die Einschränkung selbst: Jede neue Regel sollte dazu führen, dass eine alte entfernt wird, sodass nur die wirklich wichtigen Regeln übrig bleiben.
Regel 14: Halten Sie Regeln, Fähigkeiten und Arbeitsabläufe an separaten Orten
CLAUDE.md : rules that apply to every single task
.claude/skills : reference material, read only when relevant
.claude/commands : fixed step sequences, invoked by name
Warum es funktioniert: Die meisten überdimensionierten Regelfilter entstehen dadurch, dass darin tatsächlich drei verschiedene Arten von Dokumenten zusammengepackt sind. Eine Beschreibung Ihres Datenbankschemas ist keine Regel – genauso wenig wie Ihre Bereitstellungsabfolge. Sobald Sie dieses Material an einen anderen Ort verschieben, werden die verbleibenden Regeln wieder sichtbar, anstatt unterzugehen.
Regeln 15 bis 21: Sicherstellen, dass das Verhalten über eine lange Sitzung hinweg anhält
Eine Regel, der das Modell in Runde drei folgt, sie aber in Runde vierzig vergisst, war nie wirklich eine Regel. Diese Richtlinien dienen dazu, Anweisungen während der gesamten Dauer einer Sitzung beizubehalten.
Regel 15: Behalten Sie die Regeln im Dateiinhalt, nicht nur im Gespräch
Any instruction that must hold for the whole project belongs in this file.
Instructions given in conversation apply to the current task only.
Warum es funktioniert: Lange Sitzungen werden irgendwann komprimiert. Wenn diese Kompression stattfindet, werden die Details des Gesprächs zusammengefasst, während die Dateien vollständig neu geladen werden. Ein Konto aus August 2026 veranschaulicht dies genau: Ein Benutzer wies das Modell zweimal an, die Paketversion niemals zu erhöhen; es kam während des Vorgangs zur Kompression zu einer Änderung, und bei Schritt vierzig war die Version dennoch erhöht worden. Nichts ist abgestürzt oder hat einen Fehler ausgelöst – die Anweisung existierte einfach nicht mehr im Arbeitskontext des Modells.
Falls Sie feststellen, dass Sie dieselbe Anweisung im Chat mehrmals wiederholen, betrachten Sie das als Signal. Sie gehört in die Datei, nicht in Ihre Eingabe.
Regel 16: Laden Sie die Regeldatei nach der Kompression neu.
After any context compaction, re-read CLAUDE.md before the next edit.
Warum es funktioniert: Es handelt sich um eine kostengünstige Schutzmaßnahme gegen genau den Fehler, der in Regel 15 beschrieben wird, und es ist eine der wenigen Regeln, bei denen man die Einhaltung direkt durch das Durchscannen des Transkripts überprüfen kann.
Regel 17: Geben Sie den genauen Befehl an, der zur Überprüfung der Arbeit verwendet wird
## Verification
Before saying a task is done, run:
npm run typecheck && npm test -- --run
Paste the final line of output. If it fails, fix it. Do not report success.
Warum es funktioniert: Eine Anweisung wie „Stellen Sie sicher, dass die Tests bestehen“ gibt dem Modell nichts Konkretes zum Ausführen. Ein echter Shell-Befehl hingegen schon, und die Anforderung an das eingefügte Ausgabeergebnis bedeutet, dass die Behauptung eines Erfolgs auf einen Blick überprüft werden kann, anstatt ihr blind zu vertrauen.
Regel 18: Erklären Sie genau, was „erledigt“ eigentlich bedeutet
## Done
A task is done when: the change is made, typecheck passes, tests pass,
and you have stated in one sentence what changed and why.
Not done: "this should work", "you may want to verify".
Warum es funktioniert: Wenn dieser Wert undefiniert bleibt, liefert das Modell seine eigene Definition von „erledigt“, und diese Definition lautet in der Regel einfach „Ich habe etwas Text erzeugt.“ Diese einzige Regel trägt mehr dazu bei, die Anzahl der Fälle zu verringern, in denen man eine Stunde später feststellt, dass der Build tatsächlich fehlerhaft ist.
Regel 19: Beschränken Sie die Rückmeldungen auf eine einzige handlungsrelevante Änderung
When something did not work, name ONE thing to change and why.
Do not list five options.
Warum es funktioniert: Das Anbieten von fünf verschiedenen Optionen, wenn etwas fehlschlägt, ist eigentlich nur eine Art, einer Entscheidung aus dem Weg zu gehen. Zudem wird es unmöglich, herauszufinden, was das Problem tatsächlich gelöst hat, da man nicht feststellen kann, welche der fünf Vorschläge entscheidend war.
Regel 20: Fragen Sie statt zu raten
If you need information you do not have, output:
MISSING: <exactly what you need>
and stop. Do not assume a plausible value and continue.
Warum es funktioniert: Dies könnte die wertvollste Zeile in der gesamten Datei sein. Fast jedes ernsthafte Problem mit einem Agenten entsteht dadurch, dass dieser selbstbewusst eine fehlende Information ergänzt, anstatt innezuhalten und zu fragen. Eine Ablehnung kostet dreißig Sekunden. Eine selbstbewusst falsche Annahme kostet einen Nachmittag – und man bemerkt es in der Regel erst nach mehreren Änderungen.
Zuvor: Das Modell benötigt einen Warteschlangennamen, den Sie nie angegeben haben. Es verwendet standardmäßig einen Namen wie default, erstellt eine scheinbar korrekte Integration, und die Aufgaben stapeln sich in einer Warteschlange, die von nichts verarbeitet wird. Das merkt man erst Tage später.
Nachher: Es gibt MISSING: the queue name for the retry consumer aus. Sie liefern die Antwort innerhalb von fünf Sekunden, und der resultierende Code ist von Anfang an korrekt.
Es gibt eine einfache Möglichkeit, zu überprüfen, ob diese Regel tatsächlich aktiv ist: Man fragt nach etwas, das von Informationen abhängt, die man absichtlich zurückgehalten hat. Wenn das Modell dennoch antwortet, anstatt die Lücke anzugeben, existiert die Regel nur auf dem Papier.
Regel 21: Weiter reduzieren – eine Regel pro Monat
Once a month, remove any rule you have not seen violated recently.
Warum es funktioniert: Regeldateien neigen dazu, endlos zu wachsen, da das Hinzufügen einer neuen Regel wie Fortschritt wirkt, während das Entfernen einer Regel wie ein Risiko erscheint. Wenn eine Regel in den letzten Monaten nicht angewandt wurde, ist sie entweder nicht mehr notwendig oder wurde nie wirklich befolgt. In jedem Fall bindet sie bei jeder Interaktion Ressourcen. Ihr Entfernen bringt die günstigste Leistungsverbesserung.
Fünf Regeln, die gestrichen wurden
Das Entfernen von Inhalten war wichtiger als alles, was hinzugefügt wurde. Deshalb hier fünf Einträge, die ursprünglich in einer Datei mit 400 Zeilen enthalten waren und in der aktuellen Version mit 61 Zeilen fehlen. Wenn Ihnen einige davon bekannt vorkommen, können Sie sie wahrscheinlich noch heute Abend entfernen.
„Überlegen Sie das Problem Schritt für Schritt, bevor Sie codieren.“ Das ist bereits die Standardvorgehensweise. Aktuelle Versionen von Claude Code planen ihren Vorgeang bereits vor dem Bearbeiten von Dateien – ohne weitere Anweisungen. Dieser Eintrag stammt noch aus älteren Gewohnheiten und nahm lediglich Platz in Anspruch.
„Achten Sie auf Leistungsprobleme.“ Dieser Eintrag besteht bereits im Vorab-Prüftest nicht – wovon soll man genau ausgehend vorsichtig sein? Er wurde durch zwei spezifische, überprüfbare Regeln bezüglich des Datenbankzugriffs ersetzt, die tatsächlich echte Probleme erkennen.
Eine 90 Zeilen lange Beschreibung des Datenbankschemas. Das ist Dokumentation, keine Regel. Sie gehört in eine Fähigkeitsdatei, die geladen wird, wenn das Modell arbeitet, die mit der Datenbank zu tun hat, und nicht in die Datei, die vor jeder Aufgabe gelesen wird – auch dann nicht, wenn es sich um etwas So Banales wie eine CSS-Anpassung handelt. Das Herausnehmen dieses Abschnitts war die größte Einsparung überhaupt.
„Verwende niemals any in TypeScript.“ Das war zwar nicht falsch, aber überflüssig – der Linter blockiert es bereits. Alles, was die Toolchain ohnehin durchsetzt, muss keinen Platz in der Regelf Datei einnehmen. Wenn eine Verletzung im CI erkannt werden kann, soll das CI sie erkennen.
„Fügen Sie nützliche Kommentare hinzu.“ Jeder Versuch, dies zu formulieren, führte zu Kommentaren, die lediglich die darüberstehende Codezeile wiederholten. Die Lösung bestand darin, die Formulierung umzukehren: Erklären Sie nicht, was der Code tut, sondern nur, warum er es tut. Diese Version ist sowohl wirksamer als auch eine Zeile kürzer.
Dieses Muster ist in allen fünf Fällen konstant. Zwei enthielten Inhalte, die das Modell oder die Tools bereits selbst bearbeitet hatten. Zwei konnten auf keine konkrete Weise überprüft werden. Einer bestand aus Referenzmaterial, das als Regel getarnt war. Suchen Sie in Ihren eigenen Dateien nach diesen vier Kategorien – so werden die für die Löschung in Frage kommenden Elemente schnell sichtbar.
Die vollständige Datei, bereit zum Einsatz
# CLAUDE.md
## Stack
Next.js 15 App Router, TypeScript strict, Postgres via Drizzle, Vitest.## Editing
Change the minimum number of lines needed.
Do not reformat, reorder, or rename anything you were not asked to change.
Match the style already in the file.## Scope
Work only on what was asked.
Mention unrelated problems, do not fix them.
Remove imports your change made unused. Nothing else.## Abstractions
Do not add an interface with one implementation.
Do not add a config option for a value that never changes.
Functions over 40 lines must be split.## Tests
Do not edit existing tests to make failing code pass.
If a test is wrong, say so and stop.## Dependencies
Do not add packages. Use what is in package.json.
To add one: name it, name what it replaces, stop, wait.## Error Handling
Handle errors that can actually occur here.
No try/catch around code that cannot throw.## Patterns
New routes follow src/api/users/route.ts.
Components do not fetch data. Fetch in the route, pass props down.
Database access goes through src/db/queries/. Never inline SQL.## Security
Never write a key, token, password, or connection string into a file.
Never commit .env or .env.*.
Reference environment variables by name only.## Destructive Actions
Stop and ask before: dropping a table, deleting a branch, force pushing,
rewriting history, deleting a file you did not create, running a
migration against anything not local.## Verification
Before reporting done, run:
npm run typecheck && npm test -- --run
Paste the final line. If it fails, fix it. Do not report success.## Done
Done means: change made, typecheck passes, tests pass, and one sentence
saying what changed and why.## When Stuck
If you need information you do not have, output:
MISSING: <what you need>
and stop. Do not assume a value and continue.## Reporting
Name ONE thing to change. Not five options.## Persistence
Rules live here, not in chat. After compaction, re-read this file.
Das ist die gesamte Datei – sechsundsechzig Zeilen.
Was hat sich geändert
Nachdem die Datei von 400 Zeilen auf 61 reduziert wurde:
- Die Überschreibungen von Dateien wurden gestoppt. Die Regel zur präzisen Bearbeitung existierte bereits in der überdimensionierten Version. Sie wurde erst dann berücksichtigt, als sie nicht mehr irgendwo bei Zeile 213 versteckt war.
- Die
MISSING:-Regel wurde aktiviert. Sie triggert nun etwa zweimal pro Woche und hält inne, um nachzufragen, anstatt einen Konfigurationswert zu erfinden. Zuvor hätten beide Situationen zu stummen, fehlerhaften Ausgaben geführt. - Lange Sitzungen drifteten nicht mehr ab. Das Problem mit den Versionsänderungen sowie drei weitere ähnliche Probleme verschwanden, nachdem die Regeln im Dateiinhalt verankert wurden und nicht mehr über verschiedene frühere Chatnachrichten verteilt waren.
- Die Überprüfungen wurden schneller, einfach weil die Unterschiede kleiner wurden. Das ist das gesamte Prinzip – nichts Komplexeres dahinter.
Es gibt hier keinen übersichtlichen Vor- und Nach-Vergleich als Benchmark, und es wird auch keiner zum Zweck einer klaren Darstellung erstellt. Stattdessen gibt es eine Datei, die etwa eine Minute zum Lesen braucht, zusammen mit einem Verhalten, das tatsächlich mit dem übereinstimmt, was darin steht.
Nächste Schritte
- Öffnen Sie Ihre vorhandene CLAUDE.md-Datei und zählen Sie die Zeilen.
- Gehen Sie sie einmal durch und markieren Sie jede Regel, bei der Sie im Falle eines Verstoßes keinen konkreten Beleg anführen können. Entfernen Sie diese.
- Ersetzen Sie jedes „prefer“ und „try to“ durch ein klares „do not.“
- Ersetzen Sie alle Verweise auf „unsere Konventionen“ durch einen tatsächlichen Dateipfad.
- Falls Sie keine Regel ähnlich wie Regel 20 haben, fügen Sie sie hinzu. Sie ist die einzige Regel, die diese ganze Übung rechtfertigt.
Danach lassen Sie die Datei einen Monat lang unberührt. Wenn Sie wieder darauf zurückkommen, finden Sie noch etwas, das gelöscht werden kann.
Die wirklich gültigen Regeln weisen dieselben Eigenschaften auf: kurz, absolut und überprüfbar. Alles andere ist lediglich eine Notiz für einen selbst, die das Modell schließlich Hunderte Male am Tag erneut liest – ohne jeden Nutzen.
Verwandte Artikel
- Vergleich von Frontier AI Agents: Astra, Flash, Fable und Mythos — Eine Aufschlüsselung, wie die neuesten Versionen der Modelle GPT, Gemini und Claude bei echten Aufgaben wie Programmieren, Surfen und Tool-Nutzung abschneiden, nicht nur bei Benchmarks.
- Auswahl eines Python AI Agent Frameworks im Jahr 2026: Ein praktischer Vergleich — Vergleicht fünf Python AI Agent Frameworks hinsichtlich ihrer Handhabung von Fehlern und Komplexität, um Lesern zu helfen, das richtige Werkzeug für ihren Workflow zu finden.