Eine achtstufige Einrichtung für Claude Code: CLAUDE.md, Speicher, Hooks und Schutzmechanismen

Die Einrichtung bestimmt, inwieweit man der Antwort vertrauen kann

Jeder kann einen Prompt in Claude Code eingeben, doch die dazugehörige Konfiguration entscheidet darüber, ob die Ausgabe Vertrauen verdient. Im Folgenden wird Schritt für Schritt eine realistische Einrichtung für anspruchsvolle Ingenieurarbeiten vorgestellt, zusammen mit den Begründungen für jede Ebene. Es handelt sich weder um eine Liste von Funktionen noch um eine Marketingversion. Acht Ebenen zusammen ergeben etwas, das eher einem gut konfigurierten Ingenieurwerkzeug gleicht als einem Chatfenster, das zufällig Code schreibt.

Ebene 1: CLAUDE.md in zwei Skopen

Claude Code liest CLAUDE.md-Dateien in mehreren Bereichen, und die Trennung zwischen diesen Bereichen ist wichtiger, als die meisten Menschen erwarten. Eine persönliche Datei unter ~/.claude/CLAUDE.md gilt in jedem Projekt, unabhängig davon, welches Repository geöffnet ist. Jedes Projekt erhält außerdem seine eigene CLAUDE.md-Datei, die im Versionskontrollsystem gespeichert wird, sodass das gesamte Team über das Versionskontrollsystem dieselben Anweisungen erhält.

Eine einfache Regel hält die beiden Bereiche voneinander getrennt. Alles, was mit der Arbeitsweise einer Person zu tun hat – unabhängig vom Codebasis – wird in der globalen Datei aufgeführt: Regeln zur Tool-Nutzung wie die Vorzugsbehandlung einer Code-Intelligenz-Suche vor einer einfachen grep-Abfrage, Kommunikationsvorlieben und -konventionen, die überall angewandt werden sollen. Alles, was sich auf eine bestimmte Codebasis bezieht, kommt in der pro-Repo-Datei hin: Build-Befehle, Architekturentscheidungen, Namenskonventionen sowie Fehlerkategorien, die bereits in diesem Projekt aufgetreten sind. In jedem anderen Projekt wären solche Einträge unnötiger Ballast, der den Kontext unnötig überlastet.

Der Anlass, etwas aufzuschreiben, ist konkret. Stellen Sie sich ein Fehlermuster vor, das zweimal im selben Bereich eines Projekts auftaucht. Die Lösung scheint richtig zu sein und übersteht einen flüchtigen Blick, führt aber aufgrund der Tatsache, dass die zugrunde liegende Einschränkung nirgends festgehalten wurde, wo der Verantwortliche sie sehen konnte, zum gleichen Problem zurück. Beim ersten Mal wird die Einschränkung im Gespräch erläutert und alle machen weiter. Beim zweiten Mal führt derselbe Fehler zur gleichen Erklärung. Das ist das Signal. Eine Regel gehört in CLAUDE.md nicht deshalb, weil sie eines Tages nützlich sein könnte, sondern weil dadurch dasselbe Gespräch zweimal geführt werden musste. Sobald es sich um eine konkrete, überprüfbare Regel handelt und nicht um eine vage Warnung, hört das Problem auf, sich zu wiederholen.

Ein praktischer Hinweis: Der Inhalt von CLAUDE.md wird als Benachrichtigung an den Benutzer übermittelt und ist nicht im Systemprompt enthalten, daher ist Genauigkeit wichtiger als Länge. Eine Datei mit weniger als 200 Zeilen prüfbarer Regeln ist leistungsfähiger als eine lange Datei mit vagen Regeln.

Ebene 2: Auto-Memory

CLAUDE.md enthält die Anweisungen des Entwicklers an den Agenten, während das Memory das ist, was der Agent selbst ermittelt. Beide erfüllen unterschiedliche Aufgaben und sollten nicht miteinander verwechselt werden. Claude Code verfügt über ein weiteres System namens Auto-Memory, das pro Projekt aufgebaut wird und außerhalb des Repositoriums gespeichert ist; der Agent schreibt darin hinein. Es enthält vier Arten von Notizen: die Rolle und Arbeitspräferenzen des Entwicklers, bereits gegebene Korrekturen und Rückmeldungen, den laufenden Projektzustand, der nicht aus dem Code abgeleitet werden kann, sowie externe Referenzen auf Informationen außerhalb der Codebasis. Eine leichte MEMORY.md-Datei indiziert alles.

Der Unterschied besteht darin, dass CLAUDE.md absichtlich verfasste Anweisungen enthält, während das Gedächtnis den aus mehreren gemeinsamen Sitzungen gesammelten Kontext speichert, der niemals formell dokumentiert wird. Das eine ist ein Regelbuch. Das andere ähnelt dem institutionellen Wissen, das ein langjähriger Teamkollege ohne jegliches Einarbeitungsdokument mit sich trägt. Drei Beispiele zeigen, was sich ändert:

• Eine einmalige Korrektur wie „Berühren Sie diese Datei nicht, ohne vorher zu fragen“ bleibt in die nächste Sitzung über und muss nicht jedes Mal bei einem neuen Gespräch wiederholt werden.
• Der Projektzustand, der im Code nicht sichtbar ist, wird in Erinnerung behalten: eine laufende Migration, eine absichtlich aufgeschobene Entscheidung oder eine Architektur, die aus Gründen einer Einschränkung, die kein Diff zeigt, absichtlich falsch erscheint.
• Verweise darauf, wo Antworten zu finden sind, bleiben bestehen – beispielsweise welches Dashboard, welches externe Dokument oder welches System enthält das, was die Codebasis nicht mitteilen kann.

Keines davon gehört in CLAUDE.md, da es sich um keine durchgesetzte Regel handelt. Es handelt sich um Kontext, der im Moment des Schließens einer Sitzung verschwindet.

Schicht 3: Hooks als bewusste Reibung

Bewusst eingeführte Reibung ist völlig anders als Reibung, der man einfach ausgeliefert ist. Hooks laufen deterministisch ab, als echte Shell-Befehle zu festgelegten Zeitpunkten im Lebenszyklus, und das bietet eine zuverlässigere Garantie als die Hoffnung, dass das Modell sich normalerweise daran erinnert. Ein PreToolUse-Hook tritt vor jedem Toolaufruf auf und kann diesen vollständig stoppen. Ein Stop-Hook tritt auf, wenn Claude seine Antwort beendet hat, und kann sie fortsetzen, falls noch keine Bedingung erfüllt ist.

Das nützlichste Muster ist ein PreToolUse-Hook, der auf Dateiänderungen beschränkt ist. Bevor eine Änderung vorgenommen wird, wird ein schriftlicher Bericht über die Fakten gefordert: Welche Module die Datei importieren, was kaputtgehen könnte und welche Anfrage tatsächlich gestellt wurde. Er wirkt als gezielter Bremsmechanismus gegen nachlässige Änderungen, und dieser Widerstand lohnt sich, weil er genau dort eingreift, wo Vorsicht geboten ist. Im Gegensatz zur menschlichen Aufmerksamkeit ignoriert ein Hook nicht die vierzigste Änderung in einer langen Sitzung oder eilt diese überstürzt ab.

Ein zweiter Hook sorgt für Disziplin bei der Ausgabe, indem er Antworten kurz hält, überflüssigen Reflexionskram sowie vorsichtige Formulierungen entfernt, die in längeren Sitzungen auftauchen. Dabei geht es weniger um Sicherheit und mehr darum, keine Lesezeit mit unnötigem Inhalt zu verschwenden. Ein dritter Hook überwacht den Zustand des Kontexts und regt an, an einer natürlichen Grenze statt an einer willkürlichen zu komprimieren. Ein PreCompact- oder SessionStart-Hook, der mit Komprimierungsereignissen verknüpft ist, kann zu einem Zusammenfassung aufrufen, wenn das Gespräch tatsächlich einen Endpunkt erreicht hat, sodass es nicht mitten im Gedanken abgebrochen wird.

Lohnt sich dieser Aufwand? Bei der Schutzmaßnahme für Dateiänderungen auf jeden Fall, denn sie hat echte Fehler verhindert, bevor sie zu ernsthaften Problemen wurden. Die Kurzformulierungen sowie die Kontexthooks dienen eher der Anpassung an den Nutzerkomfort als zum Schutz, helfen aber, sobald sie richtig eingerichtet sind.

Layer 4: Ein Wissensgraph aus Code ist besser als grep

Grep zeigt an, wo ein String vorkommt, aber nicht, was ihn aufruft, was er selbst aufruft oder was kaputtgeht, wenn er sich ändert. Die klassische Vorgehensweise besteht aus einer Schleife: Man sucht nach einem Begriff, öffnet die Datei, sucht nach dem, was diese Datei importiert, öffnet auch diese und setzt so fort, bis ein Bild entsteht. Das funktioniert, ist aber langsam und erfordert viele Toolaufrufe, um ein aus strukturellen Fakten bestehendes mentales Modell wieder aufzubauen, das eigentlich nicht bei jeder Sitzung durch brute Force neu entdeckt werden muss.

Ein im Voraus indizierter Wissensgraph ändert die wirtschaftlichen Aspekte. Eine einzige Abfrage liefert die relevanten Quellen zusammen mit den tatsächlichen Aufrufpfaden: Wer ruft sie auf, was ruft sie auf und wie lang ist die Abhängigkeitskette. Dies geschieht in einem einzigen Durchlauf anstelle vieler Abfragen, wodurch es weniger Hin- und Herbewegungen gibt und von Anfang an ein vollständigeres Bild entsteht – schließlich werden die Details der Aufrufpfade, die grep niemals liefern könnte, einfach mit dem Ergebnis mitgeliefert. Die offizielle Dokumentation für Claude Code argumentiert ähnlich für Code-Intelligenz-Plugins und weist darauf hin, dass große, typisierte Codebasen durch strukturbezogene Abfragen im Vergleich zur Textsuche erhebliche Vorteile erlangen, da wiederholte Such- und Lesezyklen dort schnell teuer werden.

Layer 5: Überprüfung auf einem echten Gerät

Wichtig ist, ob eine Änderung auf dem Gerät funktioniert oder lediglich kompiliert wird – das sind zwei unterschiedliche Aussagen. Bei Flutter ist diese Schicht die am häufigsten verwendete. Von Grund auf neu zu bauen, um eine kleine Anpassung der Benutzeroberfläche zu überprüfen, ist verschwenderisch, wenn eine Verbindung zu einer auf echtem Hardware laufenden App möglich ist; diese Verbindung schließt Lücken, die die Codegenerierung nicht überbrücken kann. Sie ermöglicht Screenshots, das Durchklicken durch die Benutzeroberflächenfluss und die Inspektion des live angezeigten UI-Baums. Claude Code unterstützt dies nun ordnungsgemäß und bietet Zugang zum iOS-Simulator sowie Computerfunktionen, mit denen eine native Build-Datei überprüft, ein Layout-Problem nachgestellt oder ein Simulator-Fluss mit dem tatsächlich angezeigten Inhalt verglichen werden kann.

Durch die Anbindung an die Dart VM für Hot-Reload und Hot-Restart ändert sich der Ablauf von Schätzen, Neucompilieren, Warten, Überprüfen zu Schätzen, Neu laden, Überprüfen. Das ist schneller und vermeidet außerdem eine häufige Falle: die Annahme, dass ein reibungsloses Kompilieren Beweis dafür ist, dass die Korrektur funktioniert. Ein Build, das kompiliert, und ein Build, das auf dem Hardware-System korrekt funktioniert, sind zwei unterschiedliche Aussagen – eine Gewohnheit, nur neu zu kompilieren, kann sie nicht voneinander unterscheiden. Der Ausführung auf dem Gerät liefert eine klare Antwort auf diese Frage.

Layer 6: Tools nur bei Bedarf laden

Jedes Tool, das im Kontext vorhanden ist – egal ob es verwendet wird oder nicht – belastet jede Aktion, nicht nur diejenigen, bei denen es genutzt wird. Deshalb wird nicht alles standardmäßig geladen – das ist eine bewusste Designentscheidung. Spezialisierte Tools wie Browser-Automatisierung, seltener vorkommende MCP-Server sowie alles, was nur gelegentlich verwendet wird, werden auf Anfrage geladen und belegen den Kontext nicht während der gesamten Sitzung.

Die Auswirkung verstärkt sich im Laufe einer langen Sitzung, da jede Tool-Definition bei jedem Zug Kosten verursacht – unabhängig davon, ob dieser Zug das Tool tatsächlich verwendet. Die MCP-Tool-Suche in Claude Code dient dazu, dieses Problem zu überwinden. Server können sich für eine auf Anfrage erfolgende Suche registrieren, anstelle alle Definitionen zu Beginn der Sitzung vorzuladen. Dadurch bleibt eine mehrstündige Sitzung effizient und wird nicht durch nie genutzten „toten“ Kontext belastet, der weiterhin Kosten verursacht.

Layer 7: Nutzen Sie die paketierten Workflows, die Sie wirklich benötigen

Claude Code bietet ein umfangreiches Ökosystem an paketierten Workflows, darunter Code-Reviews, Sicherheitsprüfungen, framework-spezifische Prüfer sowie Planungs- und Ausführungsagenten. Jeder davon kann explizit aufgerufen werden, sodass dieselbe ad hoc-Logik nicht bei jeder Sitzung neu erstellt werden muss. Eine große Bibliothek nützt wenig, wenn nur drei Einträge verwendet werden – daher ist eine genaue Erfassung des tatsächlichen Nutzungsverhaltens besser als eine Liste des gesamten Katalogs.

Drei werden regelmäßig genutzt. Zunächst findet eine allgemeine Code-Review statt, bevor etwas Bedeutendes zusammengeführt wird. Ein auf Sicherheit fokussierter Prüfer überprüft alles, was mit Authentifizierung oder Datenerfassung zu tun hat. Ein speziell für Planung zuständiger Unteragent kümmert sich um Aufgaben, die so umfangreich sind, dass ein direkter Übergang zur Implementierung echtes architektonisches Nachdenken ausschließen würde. Diese drei decken fast alle expliziten Anwendungen ab.

Die meisten framework-spezifischen Prüfer für nicht genutzte Technologien bleiben unberührt, genauso wie die ausgefalleneren Unteragent-Muster, die für umfangreiche parallele Forschungsarbeiten entwickelt wurden. Es handelt sich dabei nicht um schlechte Werkzeuge. Die tägliche Arbeit erfordert einfach nicht dieses Ausmaß an Untersuchungen, und das Verwenden überdimensionierter Tools ist an sich schon eine Verschwendung. Der Wert liegt darin, die drei oder vier Werkzeuge zu kennen, die zuverlässig eingesetzt werden können, ohne das Gefühl zu haben, die anderen einfach nur deshalb nutzen zu müssen, weil sie vorhanden sind.

Layer 8: Bestätigung durch Umkehrbarkeit

Geschwindigkeit zählt nur dann als Vorteil, wenn das Ergebnis weiterhin zuverlässig ist; sobald das Vertrauen schwindet, wird die Geschwindigkeit zum Ursprung des Schadens. Selbst bei aktivierten allen Ebenen erfordern bestimmte Aktionen stets ausdrückliche Bestätigung: zerstörerische Git-Operationen, Pushes sowie alles, was tatsächlich nicht rückgängig gemacht werden kann. Kein Grad an Automatisierung rechtfertigt es, diese Grenze zu überschreiten – denn ein Fehler bedeutet nicht nur, die Arbeit erneut zu erledigen, sondern auch, Schäden zu beheben, die möglicherweise gar nicht behoben werden können.

Das Gleichgewicht hängt davon ab, wie rückgängig eine bestimmte Aktion ist, und nicht davon, wie riskant die Aufgabe erscheint. Eine umfassende Überarbeitung von Dutzenden von Dateien erfordert viel Aufwand, bleibt aber durch Versionskontrolle vollständig rückgängig machbar, sodass sie unter geringerer Überwachung durchgeführt werden kann. Ein git push --force erfordert fast keinen Aufwand, kann jedoch dauerhaft unkorrigierbar sein, weshalb er trotz seiner Routine streng verboten wird. Aufwand und Risiko liegen auf verschiedenen Achsen – ihre Vermischung führt dazu, dass zu viel Autonomie falschen Aktionen eingeräumt wird.

Die Entscheidung zwischen sofortiger Handlung und vorheriger Anfrage lässt sich nicht durch einen einzigen Regler steuern. Es handelt sich um eine Entscheidung pro Aktionstyp, die im Voraus getroffen wird und im Moment der Erschöpfung, in dem die Bestätigungsanfrage wie ein störender Hindernis erscheint, nicht erneut geprüft wird.

Was die Ebenen zusammenbringen

Auch keine der acht Schichten hebt sich allein hervor. CLAUDE.md ist eine Textdatei, und ein Hook ist ein Shell-Befehl, der zum richtigen Zeitpunkt ausgeführt wird. Gemeinsam verwandeln sie Claude Code von einem schnellen Tippgerät ohne anhaltenden Kontext und ohne jegliches Verständnis für Rückschritte in ein Werkzeug mit Gedächtnis, Schutzmechanismen, strukturellem Wissen über die Codebasis sowie echter Geräteverifizierung.

Die Einrichtung an sich ist nicht der interessante Teil, sondern die Begründung hinter jeder Schicht. Jeder, der Claude Code ohne diese Einstellungen verwendet, sollte nicht versuchen, alle acht Schichten auf einmal hinzuzufügen. Beginnen Sie mit einer echten CLAUDE.md, die auf Fehlern basiert, die bereits zweimal aufgetreten sind, und erweitern Sie sie anschließend schrittweise.