Ich habe mein gesamtes Claude Code Setup mit einem einzigen Befehl gelöscht. Der Wiederaufbau wurde zu einem Audit – und zu einer öffentlichen Vorlage dessen, was tatsächlich überlebt hat.
Vor drei Tagen habe ich rm -rf ~/.claude in mein Terminal getippt, absichtlich, weil ich dachte, ich würde nur den Cache leeren. Ich habe keinen Cache geleert. Ich habe meine gesamte Claude-Code-Betriebsschicht gelöscht – die globale Konfigurationsdatei, rund sechzig angesammelte Memory-Dateien, vier eigene Agenten, jeden Slash-Befehl, den ich gebaut hatte, und einen Hook, der Sitzungen automatisch in meine Notizen einordnete. Monate angesammelten Betriebswissens, weg in der Zeit, die es braucht, die Eingabetaste zu drücken.
Ich möchte präzise sein, was dieser Satz bedeutet, denn “Betriebswissen” klingt abstrakt, bis man es tatsächlich verloren hat. Das war kein Ordner mit Dokumenten. Es war die angesammelte Form, wie ich einem Werkzeug beigebracht hatte, so zu arbeiten, wie ich arbeite – welche Aufgaben wohin geleitet werden, was meine wiederkehrenden Fehler sind, wie eine gute Antwort für die Art von Fragen aussieht, die ich jede Woche stelle. Nichts davon steckt in irgendwelchen Modellgewichten. Alles davon war in diesem Verzeichnis. Und ich hatte es kein einziges Mal gesichert.
Der Teil der Geschichte, der eigentlich zählt, ist aber nicht die Löschung. Es ist, was sie überlebt hat.
Zwei Dinge bewahrten mich davor, alles vollständig zu verlieren. Erstens hatte ich in einem anderen Fenster noch eine Claude-Code-Sitzung offen, und diese Sitzung hatte meinen Memory-Index bereits in ihren Kontext geladen, bevor die Löschung stattfand – also standen die Ein-Zeilen-Zusammenfassungen dieser sechzig Memory-Dateien noch in einem Gesprächstranskript, selbst nachdem die Dateien selbst verschwunden waren. Zweitens, und wichtiger: Das dauerhafte Wissen, auf das diese Memory-Dateien verwiesen, hatte nie tatsächlich in ~/.claude gelebt. Es lebte in einem einfachen Markdown-Notizen-Vault. Das Konfigurationsverzeichnis war nur ein Zeiger, ein Index, eine Komfortschicht über der eigentlichen Sache.
Also starb der clevere Teil meines Setups – die Memory-Dateien, die eigenen Agenten, die Slash-Befehle, alles speziell für dieses Werkzeug konstruiert – sofort und vollständig. Der dumme Teil – reine Textdateien in Ordnern, kein proprietäres Format, keine Abhängigkeit vom Fortbestand irgendeiner bestimmten Software – bemerkte es nicht einmal. Ich hätte ~/.claude aus der Umlaufbahn löschen können, und das Vault wäre am Dienstagmorgen unbehelligt dort gesessen.
Das ist die Asymmetrie, über die ich immer wieder nachdenke. Die meisten Menschen, die irgendeine Art von KI-Workflow aufbauen – individuelle Anweisungen, Memory-Systeme, Agenten-Konfigurationen, wie auch immer das Werkzeug des Monats es nennt – versionieren ihren Code obsessiv und denken kein einziges Mal daran, die Schicht zu versionieren, die der KI sagt, wie sie sich verhalten soll. Wir haben “sichere deinen Code” als Reflex verinnerlicht. Niemand hat “sichere die Betriebsschicht deiner KI” verinnerlicht, weil das Werkzeug noch neu genug ist, dass es sich nicht wie Infrastruktur anfühlt. Es fühlt sich wie Einstellungen an. Man sichert keine Einstellungen.
Nur war es keine Einstellungen. Es war das sich verstärkende Ergebnis jeder Sitzung, in der ich das Werkzeug korrigiert, ihm eine Präferenz beigebracht oder eine Regel niedergeschrieben hatte, damit ich mich nicht wiederholen musste. Einstellungen sind statisch. Das hier war akkumuliert. Und akkumulierte Dinge sind genau die Dinge, die man bedauert, nicht versioniert zu haben, weil man sie nicht aus einer Spezifikation regenerieren kann – man müsste jede Korrektur, die sie hervorgebracht hat, erneut durchleben.
Das andere, das ich nicht erwartet hatte: Der Wiederaufbau zwang mich, mir anzusehen, was ich tatsächlich gebaut hatte, anstatt was ich annahm, gebaut zu haben. Stille Anhäufung verdeckt Verfall. Ein Absturz zwingt einen, jede Zeile zu lesen.
Die wiederhergestellte globale Konfigurationsdatei ging von 8,5 KB auf 6,5 KB zurück, und ich habe dabei keine einzige Regel verloren – ich habe nur das Polster um die Regeln herum entfernt, die tatsächlich Arbeit leisteten. Diese Datei zählt mehr, als ihre Größe vermuten lässt, denn sie wird nicht einmal geladen. Sie wird mit jeder einzelnen Sitzung ausgeliefert, die ich betreibe. Jeder zusätzliche Satz darin ist eine Steuer, die auf jedes Gespräch gezahlt wird, für immer, unabhängig davon, ob diese Sitzung die Regel braucht oder nicht. Aufblähung in einer solchen Datei ist keine einmalige Kosten, die man bemerkt und behebt. Es ist eine wiederkehrende Gebühr, die auf keiner Rechnung je auftaucht, weil Token-Overhead nicht als Posten erscheint – er zeigt sich als etwas schlechtere, etwas langsamere Antworten, die sich unsichtbar über Hunderte von Sitzungen hinweg verstärken, bis man sich schließlich hinsetzt und die gesamte Datei von Anfang bis Ende liest, was genau das ist, wozu mich der Verlust gezwungen hat.
Die Skills förderten ihren eigenen Verfall zutage. Drei davon verwiesen auf Slash-Befehle, die nicht mehr existierten – tote Links, die ich anscheinend schon eine Weile stillschweigend mit mir herumtrug, ohne es zu bemerken, weil ein Skill mit einer defekten Referenz keinen Fehler wirft, sondern einfach stillschweigend unterdurchschnittlich funktioniert. Und vier Agenten, direkt in meiner Konfiguration benannt, existierten als Dateien nirgendwo auf der Festplatte. Nicht “schwer zu finden”. Nicht vorhanden. Mit vollem Vertrauen referenziert, namentlich aufgerufen, und abwesend – und nichts hatte sich je beschwert, weil nichts im System es überprüfte.
Nichts davon wäre von selbst zutage getreten. Ich hätte ein funktionierendes Setup nicht auditiert. Funktionierende Dinge werden nicht auditiert; sie werden in Ruhe gelassen, bis sie kaputtgehen, und wenn sie kaputtgehen, hat man normalerweise vergessen, dass es überhaupt etwas zu prüfen gab. Die Löschung erledigte das Audit für mich, zum denkbar ungünstigsten Zeitpunkt, was der einzige Zeitpunkt ist, zu dem ein solches Audit überhaupt stattfindet.
Ich habe nicht dasselbe wieder aufgebaut. Ich habe drei spezifische Schutzmaßnahmen wiederaufgebaut, jede auf einen spezifischen Fehlermodus aus dem eigentlichen Vorfall ausgerichtet.
Die erste ist auf die beste Art langweilig: Das gesamte Konfigurationsverzeichnis ist nun versionskontrolliert, mit einem entkoppelten Git-Verzeichnis – ein Drei-Zeilen-Wrapper-Skript, das git --git-dir=~/.claude/config.git --work-tree=~/.claude ausführt, anstatt eines normalen .git-Ordners innerhalb des Verzeichnisses. Diese Unterscheidung zählt mehr, als es klingen mag. Ein normaler .git-Ordner innerhalb von ~/.claude riskiert, von anderen Werkzeugen als Projekt-Repo erkannt zu werden, oder schlimmer, in die Ignore-Regeln eines anderen Repos verschachtelt und stillschweigend übersprungen zu werden. Das entkoppelte Git-Verzeichnis lässt den Konfigurationsordner für alles andere wie einen gewöhnlichen Ordner aussehen – während er vollständig versioniert bleibt. Er wird zusätzlich in ein privates GitHub-Repo gespiegelt. Der gesamte Wert davon ist, dass ein rm -rf nun einen git clone kostet statt Monate. Ich habe nichts Ausgeklügeltes gebaut. Ich habe das Äquivalent eines Sicherheitsgurts gebaut.
Die zweite ist ein Budget-Dispatch-Baum, der innerhalb der globalen Konfiguration selbst lebt: harte Routing-Regeln, die Coding-Aufgaben an eine günstige Coding-CLI schicken, Rechercheanfragen an ein grundiertes Suchwerkzeug und lange Entwürfe an Free-Tier-Modelle – wobei der bezahlte Claude-Plan speziell für Orchestrierung und das wirklich schwierige Denken reserviert bleibt. Zusätzlich endet jede Antwort nun mit einer Modell-Zuschreibungsfußzeile, die genau benennt, welches Modell welchen Teil der Arbeit erledigt hat, einschließlich einer selbst gemeldeten Kennzeichnung für die seltenen Fälle, in denen das bezahlte Modell etwas erledigt hat, das laut Routing-Regeln hätte ausgelagert werden sollen. Der Punkt ist nicht die Ersparnis, obwohl es Ersparnisse gibt. Der Punkt ist, dass Kostendisziplin aufhört, etwas zu sein, das man drei Wochen später aus einem monatlichen Rechnungs-Dashboard ableitet, und stattdessen etwas wird, das in jeder einzelnen Antwort in Echtzeit erkennbar ist, wo man Drift tatsächlich abfangen kann, bevor sie sich verstärkt.
Die dritte ist ein SessionEnd-Hook, der jede substantielle Sitzung – fünf Nachrichten oder mehr – automatisch in das Vault einordnet: ein Ein-Zeilen-Logeintrag plus eine datierte Notiz, zusammengefasst von einem Free-Tier-Modell, gegen manuelle Aufzeichnungen abgeglichen, damit nichts dupliziert wird, und defensiv genug geschrieben, dass sie die Sitzung beim Beenden nie blockieren oder zum Absturz bringen kann. Das ist die, die mir ehrlich gesagt am meisten am Herzen liegt, denn sie schließt die eigentliche Schleife aus dem Versagen. Die Wissensbasis speist sich jetzt selbst. Vergessen, Dinge aufzuschreiben, hört auf, ein Fehlermodus zu sein, weil das System nicht mehr davon abhängt, dass ich mich daran erinnere.
Ich habe das gesamte wiederaufgebaute System bereinigt und öffentlich hochgeladen: claude-code-os. Es ist die CLAUDE.md-Vorlage, acht Skills – mehrere davon auf Matt Pococks MIT-lizenzierter Skill-Arbeit aufgebaut, im Repo entsprechend kreditiert –, die vier modell-gerouteten Agenten, der SessionEnd-Hook und das entkoppelte-Git-Verzeichnis-Wrapper-Skript. Kein Produkt. Eine Aufzeichnung dessen, was ich nach drei Tagen des teuren Herausfindens wiederaufgebaut habe, welche Teile meines Setups tragend waren und welche Dekoration.
Falls Ihnen das bekannt vorkommt – ein Konfigurationsverzeichnis, das Sie nie versioniert haben, Agenten oder Befehle, an die Sie sich halb erinnern und die Sie seit Monaten nicht überprüft haben –, haben Sie wahrscheinlich dieselbe Lücke, die ich hatte, und Sie werden sie wahrscheinlich nicht finden, bis etwas Sie zum Audit zwingt. Sie brauchen nicht den Absturz, um das Audit zu machen. Sie können einfach das claude-code-os-Repo lesen und sich die Teile holen, die die Lücke beheben, die Sie bereits haben.
Die exakte Obsidian-Vorlage und die vollständige Prompt-Kette — die strukturierte Aufnahmenotiz, der Kontrast-Prompt und die Provokations-Checkliste. Legen Sie sie in Ihr Vault und führen Sie Ihren nächsten Interessenten in vierzig Minuten hindurch.
Kein fester Rhythmus. Kein Füllmaterial. Keine gesponserten Platzierungen. Ein neuer Aufbau geht nur raus, wenn er Ihre zehn Minuten wert ist — üblicherweise alle 2–4 Wochen.
"Ich schicke Ihnen nur etwas, das ich auch geschrieben hätte, wenn mich niemand dafür bezahlt hätte. An dem Tag, an dem das nicht mehr stimmt, endet der Newsletter."