Ein CLAUDE.md von Grund auf zu schreiben – so wie in der Lektion über die erste solche Datei – ergibt Sinn, wenn du mit einem leeren Verzeichnis anfängst. Liegt im Ordner schon ein Jahr deiner Arbeit, sieht es anders aus: viel Kontext lässt sich aus diesen Dateien herauslesen, und ihn von Hand abzutippen ist eine ziemlich langweilige Arbeit.

Hier hilft /init weiter. Der Befehl geht den Projektinhalt durch und erstellt daraus eine erste Fassung von CLAUDE.md. Diese Lektion führt durch den Aufruf auf deinem eigenen Ordner und, wichtiger noch, durch das, was mit dem Ergebnis zu tun ist.

Denn das Ergebnis ist nicht fertig. Claude Code schliesst aus dem, was es sieht, und ein Teil dieser Schlüsse geht daneben – sie zu erwischen ist die heutige Aufgabe.

Nimm einen Ordner, in dem wirklich etwas liegt

Diese Übung braucht einen Ordner, bei dem du beurteilen kannst, ob das, was Claude Code darüber schreibt, stimmt. Ohne das lässt sich das Ergebnis nicht bewerten, und ums Bewerten geht es in dieser Lektion.

Nimm also etwas, das du in- und auswendig kennst: ein Projekt, an dem du seit Monaten sitzt, ein Dokumentationsverzeichnis, ein Website-Repository.

Ist der Ordner ein Git-Repository, umso besser: dann hast du git diff als zweites Augenpaar auf allem, was entsteht.

Sieh nach, was Claude Code überhaupt erkennt

Öffne ein Terminal und geh mit cd und dem Pfad in diesen Ordner, zum Beispiel cd ~/projekte/firmenseite. Starte claude und stell, bevor du /init aufrufst, eine erkundende Frage:

Schau dich in diesem Verzeichnis um und erzähl mir, was das für ein Projekt ist und wie es organisiert ist.

Die Antwort ist für sich genommen interessant, weil sie zeigt, wie viel Kontext sich allein aus der Dateistruktur ablesen lässt. Meistens einiges – Verzeichnisnamen, Konfigurationsdateien, ein README – und meistens mit ein bis zwei Stellen, an denen Claude Code einen Schluss weiter gezogen hat, als die Belege hergeben.

Merk dir diese Stellen. Gleich siehst du sie wieder, diesmal in einer Datei festgehalten, und dann sehen sie schon wie Tatsachen aus.

/init ausführen

Schreib:

/init

Claude Code arbeitet sich durch den Ordnerinhalt und baut CLAUDE.md aus dem, was es findet: Build- und Testbefehle, Konventionen, das Verzeichnislayout, alles, was sich aus den Dateien erschliessen lässt. Je nach Inhalt und Grösse des Ordners dauert das von einigen zehn Sekunden bis zu ein paar Minuten.

Eine Sache lohnt sich zu wissen, wenn du auch mit anderen Werkzeugen arbeitest: /init liest nebenbei Cursor-Regeln (.cursor/rules/ oder .cursorrules) und Copilot-Regeln (.github/copilot-instructions.md) und übernimmt daraus, was passt. Wenn deine Projektkonventionen also schon irgendwo stehen, musst du sie nicht abtippen.

Wenn es fertig ist, liegt die Datei auf der Platte. Schliess die Sitzung noch nicht.

Lass Claude Code die eigenen Vermutungen markieren

Den ersten Durchgang übergibst du dem, der die Datei geschrieben hat:

Geh das CLAUDE.md durch, das gerade entstanden ist. Schreib auf, welche Sätze du direkt aus den Dateien gelesen hast und welche deine Vermutung sind – und bei welchen du am wenigsten sicher bist.

Du bekommst eine kurze Liste statt sechzig Zeilen, und diese Liste ist das eigentliche Arbeitsmaterial. Die Vermutungen sind genau die Stellen, die nur du entscheiden kannst: Claude Code wird nicht wissen, dass die Komponente, die es gesehen hat, die Ausnahme war, die nur niemand korrigiert hat.

Vier Dinge tauchen in so einer Liste am häufigsten auf:

  1. Schlüsse aus einem einzigen Beispiel. Claude Code hat eine Komponente in einem bestimmten Stil gesehen und daraus eine Projektkonvention gemacht. Manchmal war das die Ausnahme, die nur niemand korrigiert hat.
  2. Zustandsbeschreibung statt Anweisung. «Das Projekt nutzt die Bibliothek X» ist eine Tatsache, die Claude Code ohnehin in jeder Sitzung aus den Dateien liest. Der Platz in dieser Datei gehört dem, was die Dateien nicht zeigen – warum X, und was man damit nicht tut.
  3. Veraltete Teile der Struktur. Ein Verzeichnis, das von einer früheren Version des Projekts übrig ist, wird gern wie ein lebendiger Teil des Aufbaus beschrieben.
  4. Aus dem README übernommene Befehle, die niemand mehr benutzt. Prüf, ob der angegebene Build-Befehl wirklich läuft – das ist eines der Dinge, die in einer erzeugten Datei am glaubwürdigsten aussehen und am häufigsten veraltet sind.

Es geht nicht darum, dass /init schlecht schreibt. Es geht darum, dass es aus dem schreibt, was es sieht, und du siehst mehr.

Korrigier das im Chat, nicht im Editor

Geh in die Sitzung zurück, in der die Datei entstanden ist, und diktier die Korrekturen. Was dir beim Lesen aufgefallen ist, genügt als ganz normaler Satz:

Streich in CLAUDE.md den Punkt zur Namenskonvention der Komponenten – das war eine einmalige Ausnahme, keine Projektkonvention. Wirf auch die Beschreibung des Legacy-Verzeichnisses raus, das ist seit einem halben Jahr tot.

Streichen ist bei dieser Datei ungefährlich: eine entfernte Zeile erreicht das Gespräch nicht mehr, und kaputt geht dadurch nichts.

Es lohnt sich, unbarmherzig zu sein, denn eine längere Datei wirkt schlechter. Die Dokumentation empfiehlt, unter zweihundert Zeilen zu bleiben – nicht der Ordnung halber, sondern weil eine aufgeblähte Datei Platz im Gedächtnis des Gesprächs belegt und Claude Code sich weniger genau daran hält.

Diktier danach, was Claude Code nicht wissen konnte. Das ist meist der wertvollste Teil der ganzen Datei, weil er Dinge betrifft, die in den Dateien gar nicht stehen:

  • Absprachen mit Kundinnen und Kunden, die nirgends festgehalten sind,
  • Vorgeschichte der Art «dieses Verzeichnis fassen wir nicht an, es wird separat ausgeliefert»,
  • deine eigenen Grenzen – was ohne Rückfrage passiert und was immer zur Freigabe geht,
  • Konventionen, die gelten, auch wenn der Code sie noch nicht abbildet.

Formulier das konkret. «Rück mit Tabulator ein» ist eine klare Anweisung, «schreib schönen Code» schon weniger.

Der Editor war zum Lesen der Datei gut und zu nichts sonst. Die Änderungen überlässt du Claude Code – weil es die Datei in der Form angelegt hat, die ihm passt, und weil Diktieren dieselbe Fähigkeit ist, die du bei jeder anderen Aufgabe übst.

Prüf es in einer neuen Sitzung

Die Datei wird beim Start gelesen, die laufende Sitzung kennt deine Korrekturen also nicht. Schliess sie und starte claude erneut.

Nimm etwas, das die gerade ergänzte Anweisung erzwingt. Frag nicht allgemein, ob es die Projektregeln kennt, denn dann bekommst du eine Zusammenfassung der Datei, und die beweist nichts ausser dem Laden der Datei.

Ein Missverständnis kreist um /init und lohnt sich richtigzustellen: dieser Befehl legt kein verstecktes Gedächtnis an. Er erstellt eine Datei, die du öffnen und lesen kannst, und das ist seine ganze Magie. Claude Code hat getrennt davon einen Mechanismus für automatisches Gedächtnis, in dem es sich Schlüsse aus deinen Korrekturen selbst notiert – etwas anderes, mit diesem Befehl nicht verbunden. Dazu kommt ein eigener Beitrag.

Führ /init ein zweites Mal aus

Machen wir ein kleines Experiment.

Ruf /init erneut auf, im Ordner, in dem CLAUDE.md jetzt existiert – nach deinen Korrekturen. Claude Code überschreibt die Datei nicht. Stattdessen geht es das Projekt durch und schlägt Verbesserungen zu dem vor, was schon dasteht.

Der zweite Lauf verändert, wie man über diesen Befehl denkt. /init ist kein einmaliger Assistent beim Aufsetzen eines Projekts, sondern ein Werkzeug, zu dem du zurückkommen kannst, wenn das Projekt gewachsen ist und die Datei es nicht mehr beschreibt. Nebenbei: wird die Datei zu lang, kann /doctor Vorschläge zum Kürzen erzeugen.

Beurteil die Vorschläge aus dem zweiten Lauf genauso wie die erste Fassung – lesend, nicht übernehmend. Diese Lektion handelt eigentlich durchgehend von dieser einen Gewohnheit.

/init braucht kein grosses Projekt. Es funktioniert genauso auf einem Ordner, in dem eine einzige Datei mit losen Notizen liegt – eine Mail vom Chef mit der Aufgabenbeschreibung, hingeschriebene Ideen, stichwortartige Vorgaben. Gelesen wird dann der Inhalt statt der Verzeichnisstruktur, und aus der Prosa lässt sich die eigentliche Aufgabe herausziehen. Beurteil das Ergebnis genau wie heute: lass dir zuerst die Vermutungen markieren.

Aufgaben

Hak ab, was erledigt ist. Der Stand wird im Browser gemerkt, du kannst also morgen zu dieser Liste zurückkommen.

  • Ordner mit echter, eigener Arbeit ausgewählt
  • Erkundende Frage vor /init gestellt
  • /init ausgeführt, CLAUDE.md ist entstanden
  • Liste der Vermutungen von Claude Code geholt und durchgesehen
  • Danebenliegende Stellen im Chat entfernt
  • Diktiert, was Claude Code nicht wissen konnte
  • Neue Sitzung bestätigt, dass die ergänzte Anweisung wirkt
  • Zweites /init ausgeführt, Vorschläge angeschaut statt blind übernommen