Ihr Claude Code Projekt ist nicht eingerichtet. Es sieht nur so aus.
Guter Code für Claude ist der Unterschied zwischen einer App, die funktioniert, und einem Bug-Chaos, das niemand debuggen will. Der neue Projekt-Onboarding-Flow hat diese Arbeit erheblich vereinfacht – im Grunde ein Interview. Es extrahiert das Nicht-Offensichtliche, richtet Hooks und Skills ein, stellt die Fragen, die man zu beantworten vergisst. Aber man muss trotzdem wissen, was passiert, wenn es eine bereits vorhandene CLAUDE.md findet.
Und was dann passiert, ist nicht das, was die meisten Posts beschrieben haben.
TLDR: /init ist kein verbesserter Generator. Bei einem Repo mit vorhandener CLAUDE.md wechselt es in den Audit-Modus: Es liest die Datei, gleicht sie mit Lockfiles und Configs ab und deckt auf, was nicht mehr stimmt, während der Code sich weiterentwickelt hat. Beim 4. Repo, 64 Zeilen, fand es 5 stille Lügen. Der Unterschied zwischen Generieren und Korrigieren ist der ganze Artikel.
Bei einem frischen Repo generiert es, ja. Die Community ist damit gelaufen, verständlicherweise. "Setup 10x einfacher," die CLAUDE.md schreibt sich jetzt selbst. Stimmt für ein leeres Projekt. Aber der häufigste Fall ist ein Repo, das bereits Dokumentation hat, früh geschrieben, bevor die Codebase zu dem wurde, was sie tatsächlich ist. In dem Moment, wo /init eine vorhandene Datei erkennt, ersetzt es sie nicht: es auditiert. Gleicht die CLAUDE.md mit Lockfiles, Configs, Schemas ab und deckt auf, was nicht mehr passt. Das ist der Job.
Ich habe es über ein paar Tage an 4 Repos getestet.
Ich erwartete einen Generator. Ich bekam einen Auditor.
Thariq vom Claude Code Team postete im März das env var Flag: CLAUDE_CODE_NEW_INIT=1, Preview-Modus, Interview-basierter Setup-Flow. Ein Thread auf r/ClaudeAI aus derselben Woche hatte 118 Kommentare zu einer Frage, die hängen blieb: "Mal ehrlich: wenn Claude einen langen Plan schreibt, lest ihr den wirklich? Oder sagt ihr einfach sieht gut aus?" Das Dokument, das niemand nochmal liest, war bereits ein akuter Schmerzpunkt in der Community.
Ich setzte das Flag und führte /init über die 4 Repos aus.
Was ich bei jedem erwartete: eine CLAUDE.md mit einem Stack-Bereich, einem Commands-Block, ein paar Konventionen. Boilerplate, das ich manuell aufräumen würde. Die Art von Output, die einen Startpunkt gibt und einen menschlichen Durchgang braucht, um wirklich nützlich zu sein.
Was ich stattdessen bekam: bei 3 der 4 Repos erkannte /init eine vorhandene Datei und wechselte sofort das Verhalten. Bei einem leeren Repo generiert es von Grund auf. Mit einer bereits vorhandenen Datei ist der Ansatz anders. Es liest die aktuelle CLAUDE.md, liest die Codebase, findet die Lücken, wo das Geschriebene nicht mehr dem entspricht, was der Code tatsächlich ist.
Documentation Drift kündigt sich nicht an. Es ist nicht wie ein Build-Error oder ein fehlschlagender Test. Es ist eher wie Korruption in einem Savegame: das Spiel läuft weiter, die Zahlen sehen gut aus, und dann kommt der Boss-Fight und die Stats ergeben nicht das, was versprochen war. Bis man es merkt, hat man eine Weile mit falschen Annahmen gespielt.
Claude Codes Docs beschreiben das neue /init als folgend dem "nur einschließen, was Claude nicht selbst ableiten würde" Prinzip. Bei einem vorhandenen Repo bedeutet das: erst bestimmen, was der Code tatsächlich ist, dann das mit dem Dokumentierten vergleichen, dann das Delta aufzeigen. Das Delta ist, was zählt.
2 Repos, die sich bereits kannten
Repo 1 war mein Haupt-Produkt-Dashboard: das zentrale Projekt, etwa 150-Zeilen CLAUDE.md, früh geschrieben und gelegentlich aktualisiert. /init gab 11 neue Zeilen zurück.
Die Ergänzungen waren architektonische Fakten, die nicht in der Datei standen: die zentrale Datenentität, um die sich das ganze System dreht, eine Routing-Regel, die alle Helper-Logik zu einem spezifischen Modul leitet, 2-Level Auth (Endnutzer vs. Machine-to-Machine), eine isolierte geplante Aufgabe, die außerhalb des normalen Request-Zyklus läuft. Nichts dokumentiert. Alles aus dem Code ableitbar, wenn man tief liest und die Imports querverweist.
Dann flaggte es 1 Lüge. Die CLAUDE.md referenzierte npm install und localhost:3000. bun.lock war im Root. Das Projekt lief seit Monaten auf einem anderen Port. Beides war irgendwann wahr gewesen, beides hatte stillschweigend aufgehört, wahr zu sein, und nichts war kaputt gegangen. npm-Befehle funktionieren trotzdem auf einem bun-Projekt, meistens. Der falsche Port bedeutet nur, dass man einmal die falsche URL probiert, dann die richtige, und es vergisst. Leicht zu übersehen. Leicht zu belassen.
Repo 2 war ein anderes Problem. Ein Projekt mit knapp 700 Zeilen sorgfältig gepflegter CLAUDE.md, aktualisiert nach jeder bedeutenden Änderung. /init las das Ganze, scannte die Codebase, kam mit 3 Zeilen zurück. Der bun test Runner war kürzlich hinzugefügt worden und nicht dokumentiert. Kein Rewrite, keine strukturellen Änderungen, nur die fehlenden Befehle.
Und ein Urteil: "Ihre CLAUDE.md ist bereits weit über dem, was /init hier generieren würde."
(Ich pflege ein 500-Zeilen internes Dokument zu einem völlig separaten Projekt, nichts mit alledem zu tun, das ich seit 2 Jahren aktualisiere, weil ich das Schreiben klärend finde. Meine Tochter kam einmal rein, während ich einen Abschnittstitel umschrieb, und fragte, warum ich ein Buch über meinen Code schreibe. Ich hatte keine gute Antwort. Jedenfalls.)
Ein Tool, das weiß, wann es aufhören muss, ist so selten wie eines, das weiß, wann es anfangen soll.
Das Repo ohne Karte
Das 3. Repo: ein Multi-Frontend-Katalog-Delivery-System. Mehrere Astro-Frontends, ein Hono-Backend, SQLite, keine CLAUDE.md, keine README im Root. Schnell gestartet, weil die Form klar war, Dokumentation war für später, und später bewegte sich immer weiter.
/init gab eine komplette Architektur-Karte in 4 parallelen Tool-Durchgängen zurück. Die unabhängigen Reads gehen gleichzeitig raus: Root-Config, Hono-Routes, Astro-Configs, Build-Scripts, Deploy-Notes. Die Rekonstruktion ist schnell, weil die Calls nicht aufeinander warten.
Das gleiche Prinzip gilt hier wie bei how Claude Code builds project context from an existing codebase: eine strukturierte, akkurate Karte ist fast immer die Arbeit, die nachfolgende Sessions davon abhält, schiefzulaufen. Die Karte existiert entweder und ist korrekt, oder das Modell improvisiert, und Improvisieren auf dem falschen Bild potenziert sich schnell.
Die Schlüssel-Invariante, die es aufdeckte und die ich nicht aufgeschrieben hätte: Astro läuft unter Node, alles andere unter Bun. Dieses Detail war in einem Kommentar im Deploy-Script und einem fnm use 22 Call im Build-Script vergraben. Eine architektonische Beschränkung spezifisch dafür, wie Astros Build-Prozess funktioniert, völlig undokumentiert. Jede Claude Code Session an diesem Repo hatte ohne sie operiert.
Was die 4 Durchgänge konkret zusammenstellten: das SQLite-Schema, eine Export-Pipeline, die Content zu per-Site JSON-Bundles serialisiert, die Astro-Build-Sequenz unter Node 22 (nicht Bun, weil Astros SSG-Renderer es erforderte), einen rsync-Schritt zu nginx mit bereits definierten Rewrite-Regeln, und einen Cloudflare Worker, der Edge-Routing vor dem ganzen System handhabt. Die volle Delivery-Chain von rohen SQLite-Zeilen zu gerenderten statischen Dateien hinter Cloudflare, in einem Durchgang dokumentiert. Kein Directory-Tree, keine generischen Projekt-Ratschläge. Spezifisch genug, um zu navigieren, ohne zu fragen.
5 Lügen in 64 Zeilen
Das 4. Repo: meine Produkt-Processing-Pipeline. Full Stack, Convex-Backend, Vite/Express-Frontend, Secrets verwaltet über Infisical. Die CLAUDE.md hatte 64 Zeilen, vor 3 Monaten geschrieben, damals akkurat.
/init fand 5 Stellen, wo die Dokumentation stillschweigend zu Fiktion geworden war.
1. Der Package Manager
Die CLAUDE.md instruierte: npm install, npm run dev. bun.lock war im Root. Die Migration zu bun war irgendwann passiert und die Docs waren nicht gefolgt. Claude Code hatte npm-Befehle auf einem bun-Projekt ausgeführt, stillschweigend, ohne Fehler, weil die meisten npm-Befehle trotzdem funktionieren. Die Inkompatibilität versteckt sich, bis die Dependency-Resolution divergiert und man einen Nachmittag damit verbringt herauszufinden, warum.
2. Die fehlenden Workflow-States
Die CLAUDE.md dokumentierte 3 Order-Status-Codes im Convex-Schema: draft, published, archived. Das tatsächliche Schema hatte 7. Die 4 fehlenden behandelten Edge Cases: processing, failed, review, scheduled. Die States, die für jede nicht-triviale Operation wichtig sind. Jede Claude Code Session hatte Logik gegen ein Modell des Systems geschrieben, dem 4 States fehlten.
3. Der Convex-Ordner
Die CLAUDE.md beschrieb convex/ als den Haupt-Processing-Layer. Das war früh wahr gewesen. Über 3 Monate war die schwere Arbeit in server.js migriert: PDF-Generierung für Produktblätter, Image-Resizing, Webhook-Dispatch zu Partner-Integrationen. Die Convex-Funktionen wurden zu dünnem Routing. Das tatsächliche Processing passierte in einer Datei, die die Docs aufgehört hatten zu erwähnen.
4. Der undokumentierte Mode Switch
Ein Shell-Script im Root schaltete den Stack zwischen verwaltetem Convex Cloud und einer selbst-gehosteten Convex-Instanz je nach Deployment-Target um. Null Erwähnung in der CLAUDE.md. Jede Claude Code Session hatte eine statische Backend-Verbindung angenommen, wo es einen manuellen Switch-Schritt mit echten Konsequenzen dafür gab, wo Daten landeten.
5. Der Port, der 3 Dateien zum Finden braucht
Die CLAUDE.md sagte, der Dev-Server läuft auf Port 3150. Der tatsächliche Port: 3002. Vite proxied zu Express auf 3002, PORT wurde von Infisical injiziert, vite.config.ts war die Brücke zwischen allen 3. Um den echten Port zu finden, musste man 3 Dateien querverweisen. /init machte diese Querverweise. Ich hatte es nicht. 3 Monate lang.
Niemand log absichtlich. Die CLAUDE.md war akkurat gewesen. Der Code hatte sich bewegt, wie Code sich immer bewegt: nicht in dramatischen Rewrites, sondern in 10 Entscheidungen pro Woche, jede zu klein, um sich anzufühlen, als würde sie ein Doc-Update rechtfertigen. Nach 3 Monaten waren 5 dieser Entscheidungen über das Geschriebene hinausgedriftet.
Zwischenspiel: der schmutzige Git Tree
Dieses Repo hatte uncommitted State. Eine gelöschte package-lock.json, eine untracked Backup-Datei im Root. /init übersprang das Repo nicht, forcierte den Tree nicht, schrieb nicht über das Working Directory.
Es führte 5 Git-Schritte in Sequenz aus: erstellte einen Worktree auf einem dedizierten Branch, machte Edits in Isolation, committete mit einer konventionellen Commit-Message, fast-forward merged in main, dann räumte den Worktree auf und löschte den Branch. WIP unberührt, Git-History sauber.
Der Grund, warum das sauber funktionierte: versionierte Git Hooks, die diesen Workflow durchsetzen. Das Modell wählte nicht Vorsicht. Es operierte innerhalb von Projekt-Constraints, die es nicht umgehen konnte. Das ist eine andere Garantie als sich auf das Wohlwollen des Modells zu verlassen, und es lohnt sich, den Unterschied zwischen Modell-Wohlwollen und echter Tooling-Disziplin zu verstehen, bevor man entscheidet, wie viel Vertrauen man in beides setzt.
Was /init nicht kann
/init auditiert, was nachverfolgbar ist. Dateien, die es lesen kann, Configs, die es querverweisen kann, Schemas, die es gegen Dokumentation vergleichen kann. Das ist eine echte Fähigkeit, unterschätzt, weil der Output einfach aussieht. Allein die Port-Lüge ersparte mir eine Debug-Session, die ich nicht haben wollte.
Aber es gibt eine Kategorie von Wissen, die es nicht berühren kann.
Der Git Hook, der den Worktree-Workflow forcierte, existiert, weil ich vor Monaten, bevor /init existierte, nah daran war, eine Live-Working-Session zu löschen, indem ich einen Claude Code Run direkt zu main auf einem schmutzigen Tree committen ließ. Der Hook war der Fix, den ich an diesem Nachmittag codierte. Er ist in seinem eigenen Code dokumentiert, aber nicht in irgendeiner CLAUDE.md. /init sah den Hook und referenzierte ihn korrekt, aber es konnte mir nicht sagen, warum die Sequenz wichtig war, oder was passieren würde, wenn jemand ihn löschte in der Annahme, es wäre Boilerplate-Cleanup, oder was der Nachmittag, der ihn produzierte, an verlorener Arbeit gekostet hatte.
Dieses Wissen lebt im Incident. Die wertvollsten Projekt-Regeln kommen tendenziell von etwas, das kaputt ging, nicht von einem File-Scan oder einem Onboarding-Interview. Man kann das Was dokumentieren, aber nicht die Geschichte des Warum, und das Warum ist normalerweise der Teil, der verhindert, dass sich der Fehler wiederholt. /init ist ein Audit-Tool, keine Retrospektive. Es findet gegenwärtige Lügen, nicht vergangene Lektionen, und diesen Unterschied zu kennen ist der größte Teil des Grundes, dem zu vertrauen, was es aufdeckt.
Ich denke, die andere Hälfte, /init nützlich zu machen, ist, die Dokumentation in einen Zustand zu bringen, der es wert ist, auditiert zu werden. Wenn man früh in einem Projekt ist, ist die Lücke zwischen "was ich beabsichtige, dass diese Codebase ist" und "was Claude Code tatsächlich dokumentiert braucht" die Arbeit, die Vibe Coding, For Real kartiert, spezifisch die Unterscheidung zwischen Intent-Dokumentation und Implementation-Dokumentation. /init ist nur bei Implementation nützlich. Die Absicht zu schreiben ist immer noch deine Aufgabe.
Starte /init heute Nacht auf deinem ältesten Repo. Nicht um eine saubere CLAUDE.md zu bekommen. Um herauszufinden, wie viele Zeilen bereits lügen. 😬
Quellen
- Thariq (@trq212), Claude Code Team: X-Post mit Ankündigung CLAUDE_CODE_NEW_INIT=1, März 2026
- Claude Code Docs, Woche 16 Changelog (13.-17. April 2026)
- r/ClaudeAI, GummySearch Community-Daten, Juni 2026
- wmedia.es: "/init in Claude Code: way more than a CLAUDE.md template," April 2026
Dieser Post kann Affiliate-Links enthalten. Wenn du sie klickst, verdiene ich möglicherweise eine kleine Provision (kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel zu liefern).