Mein Obsidian-Vault bekommt ein Gehirn

Okay, das hier könnte ein wenig technischer sein als die bisherigen Beiträge. Aber ich lasse es mal so. Bitte weitergehen, falls es euch nicht interessiert.

Ich suche schon viel zu lange. Vor jedem Workshop dasselbe Ritual: Mein lokales Dokumentensystem (seit > 10 Jahren DEVONthink) aufmachen, Suchfunktion nutzen, nach dem richtigen Ordner graben, Clippings durchscrollen, Readwise-Highlights überfliegen, dann noch schnell die Projektdatei suchen. Alles in Obsidian checken, was ich beim letzten Mal mit dem Kunden gemacht habe, wer da war, wie der Ablauf war. Am Ende habe ich alles irgendwie zusammen, aber das kostet Zeit, die ich eigentlich nicht habe.

Heute habe ich damit angefangen, das zu ändern.

Das Problem: Wissen ist da, aber nicht abrufbar

Ich arbeite seit etlichen Jahren mit Obsidian als Herzstück meines Arbeitssystems. Ich habe es hier immer mal wieder erwähnt und Obsidian ist ein Kaninchenbau, der alleine schon einen Beitrag hier wert ist. (Love it or leave it!)

In Obsidian steckt mein CRM, meine Projektverwaltung und -planung, Website-Sync, Notizen, Clippings, Fachartikel. Nahezu alles, was eben kein Dokument im Sinne von pdf oder eBook ist. Der Vault (= das, wo das alles drinliegt) ist gewachsen und nützlich, aber für eine bestimmte Aufgabe taugt er nicht gut: das schnelle, thematische Abfragen von Wissen vor Workshops oder Beratungsgesprächen.

Das Material ist da. Studien in DEVONthink, Artikel im Clippings-Ordner, Readwise-Highlights aus Büchern, Transkripte von Webinaren. Aber alles liegt verstreut, unverbunden, kaum durchsuchbar. Wenn ich wissen will, was ich schon über KI-Workshops in der Altenhilfe weiß, muss ich das selbst zusammensuchen.

Andrej Karpathy hat das in einem Beitrag (März 2025) mal so beschrieben: Er nennt es „Compiling knowledge". Ein LLM liest rohe Quellen und verdichtet sie zu einem strukturierten, abfragbaren Wissensarchiv. Das LLM schreibt und pflegt das Wiki. Der Mensch kuratiert die Quellen und stellt Fragen. Genau das wollte ich.

Die Idee: ein abgekapseltes Wiki im bestehenden Vault

Das Thema liegt gerade in der Luft. Überall taucht gerade auf, was Karpathy beschrieben hat: Kein neues System aufbauen, kein weiteres Tool einführen.

Das Wiki lebt als eigenständiger Ordner /llm-wiki direkt im Vault. Claude Code wird aus diesem Ordner heraus gestartet, liest dort eine CLAUDE.md mit allen Regeln, und kann dann lesend auf bestimmte Vault-Bereiche zugreifen. Schreiben darf es nur innerhalb von /llm-wiki.

Der Rest des Vaults bleibt unangetastet. CRM, Projekte, Website-Sync. Alles wie vorher.

Das ist der entscheidende Punkt: Es ist eine zusätzliche Schicht, kein Umbau

Ein weiteres Argument ist, dass dieses ganze System unabhängig sein muss von einem einzusetzenden Werkzeug (LLM). Diese Philosophie ist mir seit Jahren sympathisch und allein aus diesem Grund arbeite ich mit Obsidian. Dort gilt die Philosophie "File over App". Die Daten gehören mir und sind unabhängig von dem Werkzeug, in diesem Fall Obsidian, komplett und weiter editierbar und nutzbar. Egal ob es Obsidian gibt oder nicht. Reine Textdateien, reines Wissen in Markdown. All das, was auch Skills benötigen, was wiederum aber ein anderes Thema ist.

Diesen Lock-in-Effekt wollte ich um alles verhindern und das war der Grund, warum ich mich bislang auch immer gegen andere Systeme gewehrt habe.

Ich bin wirklich froh, dass ich bereits mindestens 10 Jahren nahezu ausschließlich mit Markdown arbeite. Nix proprietäres, kein Microsoft oder was auch immer. Reiner Text in reinen Buchstaben und Zahlen. Wunderbar. Und genau das ist das, was jetzt wieder gebraucht wird. Beschäftigt euch damit. Es ist wirklich einfach. Und in den Organisationen wird auf kurz oder lang anstehen, das vorhandene Wissen in Reintext umzuwandeln, davon bin ich fest überzeugt.

Das Prinzip gilt übrigens unabhängig vom Tool. Wer kein Obsidian nutzt, kann denselben Ansatz mit Notion, Logseq oder schlicht einem Ordner voller Markdown-Dateien bauen. Der entscheidende Punkt ist nicht das Werkzeug, sondern die Trennung: hier das bestehende System, da die KI-Schicht.

Der Setup-Prozess: Claude als Bauarbeiter

Seit einiger Zeit habe ich mir auch angewöhnt, meine Prozesse mit Claude Code oder Cowork von der reinen Planung zu trennen. Ja, ich weiß, es gibt den Planungsmodus, aber bei komplexeren Dingen trenne ich das trotzdem immer noch einmal.

So habe ich mit Claude Chat das Transkript einer Audioaufzeichnung meiner Ideen gefüttert und gemeinsam einen detaillierten Bauplan für das Vorhaben entwickelt.

Im Anschluss hab ich Chat einen guten Prompt für die Umsetzung dieses Plans erstellen lassen und dies dann Claude Code gegeben. Claude Code hat dann als Setup-Agenten agiert. Das heißt: Ich habe Claude nicht gefragt, ob es mir erklärt, wie man sowas aufbaut. Ich habe es angewiesen, das Setup Schritt für Schritt durchzuführen, und nach jedem Schritt auf meine Bestätigung gewartet.

Schritt für Schritt, mit Bestätigungen.

Bevor Claude irgendetwas verschiebt oder löscht, zeigt es mir was es vorfindet und was es tun will. Ich bestätige oder korrigiere. Kein blindes Durchlaufen.

Ja, fast vergessen: Wenn ihr sowas baut, vorher ans Backup denken. Klar, oder?

Bestandsaufnahme zuerst.

Claude hat beim Start geprüft, was schon da ist. Da waren noch Rudimente von manuellen Versuchen, die weg mussten. Ging schnell.

Ich habe mich dazu entschlossen, mein Wissen zunächst mit zwei Themen aufzubauen. Das muss alles Stück für Stück gehen und wird auch noch weiterhin aufwändig sein. Diese ersten beiden Themen könnt ihr unten sehen: Fundraising und Generative KI. Kann bei euch natürlich anders sein.

Am Ende des Setups:

Git-Repo initialisiert, erster Commit gesetzt.

Das Gehirn: die CLAUDE.md

Die wichtigste Datei des ganzen Systems ist die CLAUDE.md. Sie wird von Claude Code automatisch geladen, sobald ein neuer Assistent aus /llm-wiki gestartet wird.

Darin steht alles: Welche Ordner darf Claude schreiben? Welche nur lesen? Was ist tabu? Wie sieht das Frontmatter einer Wiki-Seite aus? Wie läuft ein Ingest (das Einspielen und Aufbereiten neuer Quellen) ab, wie eine Query, wie ein Lint (eine Qualitätsprüfung des bestehenden Inhalts)?

Ein paar Punkte, die mir besonders wichtig waren:
Mein Obsidian ist nicht wie eine normale Obsidian-Installation. Ich habe dort einige Automatismen laufen, als auch den schon beschriebenen Push zu meiner Website, mit der ich die KI-Links pflege. Außerdem habe ich ein CRM gebaut, das ebenfalls Obsidian als Datenbasis hat. An dieser ganzen Architektur darf nichts verändert werden, sonst fliegt mir alles um die Ohren.

Der großartige Kollege Jona Hölderle hat mich auch nochmal drauf gebracht, bei größeren Projekten zusätzlich eine developer.md (für einen möglichen Nachbau und als Art Protokoll) und eine readme.md (für mich selbst "für später") mitzuentwickeln. Ein wirklich sehr hilfreicher Tipp, falls ihr es mal braucht.

Schutzzonen sind explizit.
Teile des /Areas/KI-Ordners im Vault werden automatisch mit meiner Website synchronisiert. Wenn Claude dort etwas verändert, gibt es einen Konflikt. Die CLAUDE.md sagt deshalb: lesen ja, schreiben niemals. Und jede Wiki-Seite, die Material aus diesem Ordner nutzt, bekommt einen Warnvermerk.

Token-Effizienz ist eingebaut.
Maximal 3 bis 5 Quellen pro Session. Vor jedem Ingest wird wiki/log.md geprüft, damit nichts doppelt verarbeitet wird. Zuerst index.md lesen, dann gezielt einzelne Seiten öffnen. Das hält die Kosten kalkulierbar.

Wikilinks mit Bedacht.
Weil der Vault schon tausende Dateien hat, nutzt Claude für interne Wiki-Links immer relative Pfade: [[wiki/konzepte/ki-und-lehre]] statt [[KI und Lehre]]. Für Verlinkungen auf CRM-Einträge oder Projekte verwendet es den genauen Obsidian-Dateinamen: [[Ruhrpott Beispielverein e.V.]].

Was direkt funktioniert hat (und was nicht)

Der erste richtige Ingest war noch am selben Tag: zwei Fachartikel über KI-Slop. Claude hat beide Quellen gelesen, eine Konzeptseite zu „KI-Slop" angelegt, zwei Quellenseiten erstellt, alles verknüpft und den Index aktualisiert. Das hat gut funktioniert. Dann eine Query zur Workshop-Anfrage einer Altenhilfe-Einrichtung. Claude hat die Projektdateien gelesen, CRM-Daten abgerufen, existierende Wiki-Seiten konsultiert und daraus eine Synthese-Seite erstellt: Workshop-Baukasten, Modulübersicht, branchenspezifische Tools, CRM-Übersicht der relevanten Organisationen. Dafür allein hätte ich eine Stunde gebraucht.

Aber: Bugs.

YAML-Problem: Wenn ein Titel deutsche Anführungszeichen enthält (wie „KI verschiebt die Struktur der Lehre"), und der YAML-String mit ASCII-Anführungszeichen umschlossen wird, bricht der Parser. Obsidian zeigt dann Fehlermeldungen in den Properties.
Fix: immer Single Quotes als äußere Begrenzung verwenden, wenn der Inhalt Anführungszeichen enthält.

Ingest-Blindheit: Claude hat beim ersten Ingest nur den Ordner /raw gescannt, weitere freigebene Ordner mit Clippings und Readwise-Highlights. Das liegt daran, dass die CLAUDE.md zwar diese Ordner als „lesbar" definiert, aber der Ingest-Workflow nicht explizit angewiesen hat, sie aktiv zu durchsuchen. Das ist jetzt nachgebessert: Claude präsentiert vor jedem Ingest eine Kandidatenliste aus allen freigegebenen Pfaden.

Verlinkung auf CRM-Einträge: Der erste Ingest hat Organisationen als Fließtext erwähnt statt als Obsidian-Links. Die CLAUDE.md sagt jetzt explizit: Vor dem Schreiben in den CRM-Ordnern nachschlagen, genauen Dateinamen finden, als [[Wikilink]] setzen. Somit ist es möglich, in den Synthesen-Dateien direkt die Obsidian-Funktionalitäten zu nutzen.

Ein halber Tag. 22 Seiten. Und das Gefühl, das sich was ändert.

Stand heute nach einem Tag:

• 6 Konzeptseiten exemplarisch (KI-Slop, KI und Lehre, Großspenden-Fundraising, Database-Fundraising)

• 15 Quellenseiten

• 1 Synthese (Workshop-Baukasten Altenhilfe)

• Vollständig verknüpft mit Projekten und CRM-Einträgen

Ich kann das System also sowas fragen wie:

Und das nach einem halben Tag Setup plus ersten Ingests.
Interessanter als die Zahlen ist das Gefühl beim Testen: Die Synthese-Seite über KI-Workshops in der Altenhilfe hat Claude aus vier Projektdateien, zwei Wiki-Seiten und CRM-Daten zusammengesetzt. Das ist genau das, wofür ich sonst morgens eine Stunde brauche, wenn ich Workshops vorbereite. Und ich habe noch gar nicht angefangen, das ganze Wissen da reinzuarbeiten.

Noch nicht fertig. Das ist der Plan.

Die /raw-Ordner sind noch leer bis auf die ersten Test-Ingests aus Clippings und Readwise. DEVONthink-Material muss noch exportiert werden. Und es gibt offene Entscheidungen: Welches Thema hat das meiste Material? Wann ist ein Wiki groß genug, um verlässliche Antworten zu geben? Und vor allem wie gehe ich jetzt strategisch mit der Befüllung vor? Stichwort dazu ist auch die Frage nach einem optimalen pdf to Markdown-Konverter. Hab da mal was zu gebaut, das ging auch, aber dieses Github-Repo ist besser. Auch hier erneut Danke, Jona!

Folgende Phasen stehen an:

• Phase 1: Pilotthema nehmen, 5 bis 10 weitere Dokumente, erster echter Ingest-Durchgang

• Phase 2: Readwise-Pipeline aktivieren, Clippings systematisch ingestieren

• Phase 3: Workshop-Praxistest (Briefing aus dem Wiki erstellen)

• Phase 4: Skalieren, weitere Themenbereiche aufbauen

Das klingt nach viel. Aber Phase 1 ist ein Nachmittag Arbeit, wenn das Material vorliegt.

Jetzt geht's eigentlich erst los.

Ich habe den Setup-Agenten-Modus von Claude Code schon für Code-Projekte genutzt, aber nicht für Infrastruktur-Setups mit so vielen Abhängigkeiten (bestehender Vault, iCloud-Sync, Obsidian-Plugins, Git, Schutzregeln). Es hat erstaunlich gut funktioniert, wenn man die richtigen Absicherungen einbaut: Schritt-für-Schritt-Bestätigungen, explizite Schutzregeln in der CLAUDE.md, Git als Sicherheitsnetz.

Das ist das eigentlich Neue an diesem Ansatz. Nicht das Wiki selbst ist neu, auch nicht das Konzept, LLMs als Wissenskompilierer einzusetzen. Neu ist die Kombination: ein bestehendes, gewachsenes Arbeitssystem, das eine abgekapselte KI-Schicht bekommt, die es versteht, was sie anfassen darf und was nicht.

Ich schreibe in drei Monaten, was daraus geworden ist.