Claude Code & Obsidian: Die ultimative Anleitung für dein lokales „Zweites Gehirn“

Dieses System verwandelt Obsidian von einer einfachen Notiz-App in ein aktives, lernendes Betriebssystem. Während Obsidian dein Gedächtnis ist, fungiert Claude Code (das CLI-Tool von Anthropic) als dein Mitarbeiter, der Dokumente liest, schreibt, verknüpft und Aufgaben verwaltet.

Teil 1: Die Installation für absolute Einsteiger

1. Obsidian – Dein Container

• Was ist das? Stell es dir vor wie eine lokale Wikipedia auf deinem PC.

• Installation: obsidian.md herunterladen und installieren.

• Der erste Start: Klicke auf „Create new vault“. Wähle einen Namen (z.B. „MeinGehirn“) und einen Speicherort auf deiner Festplatte. Wichtig: Da du SQL-Profi bist – ein Vault ist technisch gesehen einfach nur ein Windows-Ordner voller Textdateien.

2. Node.js – Der Motor für Claude Code

• Warum? Claude Code läuft nicht als normales Programm, sondern über die Konsole (Terminal). Dafür braucht dein PC die „Sprache“ Node.js.

• Installation: Lade die LTS-Version von nodejs.org herunter und installiere sie mit allen Standardeinstellungen.

3. Claude Code installieren

• Öffne dein Terminal (Suche bei Windows nach „PowerShell“).

• Tippe diesen Befehl ein und drücke Enter:

  npm install -g @anthropic-ai/claude-code

• Danach tippst du claude ein. Du wirst aufgefordert, dich in deinem Anthropic-Konto einzuloggen und einen API-Key zu erstellen. Folge einfach den Anweisungen im Browserfenster, das sich öffnet.

Teil 2: Die Struktur (Das „Igor-Modell“ im Detail)

Julian Ivanov betont, dass Claude nur so gut ist wie seine Ordnung. Du musst Obsidian in Ordner unterteilen. Erstelle in der Seitenleiste von Obsidian über das Ordner-Symbol folgende Struktur:

Die magische Datei: CLAUDE.md

Erstelle im Hauptordner deines Vaults eine Datei namens CLAUDE.md. Das ist die „Betriebsanleitung“ für die KI. Kopiere diesen Text (basierend auf Julians Video) hinein:

Rolle: Du bist mein persönlicher Wissensmanager.

Struktur: > – Nutze immer [[Verknüpfungen]], um Dateien zu verbinden.

• Neue Erkenntnisse kommen in 30_Library.

• Projekte werden in 20_Projects verwaltet.

  Stil: Antworte kurz, präzise und achte auf meine hinterlegten Schreibregeln in 00_Context/Schreibstil.md.

Teil 3: Verbindung & „Skills“ (Das Arnie-Modell)

Arnie nutzt „Claude Code“ direkt auf dem Dateiordner. Das ist mächtiger als ein einfaches Plugin.

1. Obsidian Skills installieren

Damit Claude in deinem Tresor „aufräumen“ kann (Dateien verschieben, verlinken, suchen), braucht er Werkzeuge.

• Gehe im Terminal in deinen Vault-Ordner: cd "Pfad/zu/deinem/Vault"

• Installiere die Skills von Kepano (CEO von Obsidian):

  git clone https://github.com/kepano/obsidian-skills .claude/skills

• Der Effekt: Wenn du jetzt im Terminal claude startest, kann er Befehle ausführen wie: „Suche in meinen Notizen nach allen SQL-Abfragen für DB2 und fasse sie zusammen.“

2. Der „Graph View“ Trick

Arnie zeigt im Video die bunten Punkte. In Obsidian klickst du links auf das Symbol, das aussieht wie ein Netzwerk (Graph View).

• Einstellung: Klicke im Graphen auf das Zahnrad (Groups).

• Farben: Füge eine Gruppe hinzu mit der Regel path: 00_Context und gib ihr die Farbe Blau. Mache das für alle Ordner. So siehst du visuell, wie dein Wissen wächst.

Teil 4: Dein Projekt-Workflow (Das Workspace-Template)

Da du ein Template mit dem Befehl /start nutzt, ist hier die perfekte Vorgehensweise in Obsidian:

Schritt 1: Das Template-Setup

Lege dein Workspace-Template unter 90_System/Workspace_Template.md ab. In Obsidian nutzt du dafür am besten das Community-Plugin „Templater“.

Schritt 2: Ein neues Projekt anlegen

1. Erstelle einen neuen Ordner unter 20_Projects/Projekt_A.

2. Erstelle darin eine neue Datei (z.B. Setup.md).

3. Führe dein Template aus (dein /start Prozess).

Schritt 3: Der Claude-Workflow (Das Beispiel)

Stell dir vor, du planst ein neues SQL-Dashboard für die AS400.

1. In Obsidian: Du öffnest die Setup.md im Projektordner. Das Template fragt: „Wer ist der Autor?“ – Du tippst: MN. „Was ist das Ziel?“ – Du tippst: KPI Konsolidierung Version 3.3.

2. Verbindung zur KI: Du öffnest dein Terminal im Projektordner und startest claude.

3. Der Prompt: > „Claude, schau dir die Datei Setup.md in diesem Ordner an. Ich habe dort mein Projekt-Template ausgefüllt. Basierend auf meinen Zielen und den Infos über meine SQL-Umgebung in 00_Context, erstelle mir einen detaillierten Projektplan. Verlinke dabei zu bestehenden Snippets aus meiner 30_Library.“

4. Das Ergebnis: Claude schreibt dir eine neue Datei Projektplan.md direkt in deinen Ordner, setzt automatisch Links zu deinen alten Notizen (z.B. [[SQL_Server_2022_Tricks]]) und erinnert dich an deine Termine.

Benötigte Tools & Links Zusammenfassung:

• Plugin „Templater“: In Obsidian unter Community Plugins suchen (für dein /start System).

• Plugin „Claudian“: Wenn du den Chat lieber innerhalb von Obsidian statt im Terminal willst.

• Web Clipper: Hier laden, um Infos für die 30_Library per Klick aus dem Browser zu speichern.

Der Karpathy / Arnie Standard-Prompt (Übersetzt & Optimiert)

Kopiere diesen Text in deine CLAUDE.md Datei im Hauptverzeichnis deines Obsidian-Vaults. Er dient als dauerhafte Anweisung für die KI:

Du bist ein Expert-Agent für Wissensmanagement. Deine Aufgabe ist es, diesen lokalen Obsidian-Vault zu verwalten und zu erweitern. Arbeite nach folgenden Prinzipien:

1. Dateistruktur nutzen: Organisiere Informationen in den Ordnern Concepts, Entities, Sources und Index. (Hinweis: Du kannst dies auf deine Ordner wie 10_Projects etc. anpassen).

2. Atomare Notizen: Erstelle für jedes neue Konzept, jedes Tool und jede Person eine eigene kleine Markdown-Datei.

3. Intelligente Verlinkung: Nutze die Obsidian-Syntax [[Dateiname]], um neue Informationen sofort mit bestehendem Wissen zu verknüpfen. Wenn du über SQL Server 2022 schreibst, prüfe, ob es bereits eine Datei dazu gibt und verlinke sie.

4. Logging: Führe ein Logbuch im Ordner Index/Log, in dem du kurz festhältst, welche Informationen du heute hinzugefügt oder aktualisiert hast.

5. Identität: Wenn der Nutzer Informationen liefert, extrahiere „Entities“ (Personen, Firmen, Hardware) und „Concepts“ (Techniken, Ideen).

6. Kein Duplikat: Bevor du eine neue Datei anlegst, suche im Vault, ob das Thema bereits existiert. Falls ja, ergänze die bestehende Datei.

Dein Ziel ist ein hochgradig vernetztes „Second Brain“, das durch jede Interaktion wertvoller wird.

So wendest du den Prompt in der Praxis an

Damit Claude wirklich so arbeitet wie im Video von Arnie gezeigt, musst du ihm beim Start in der Konsole (Claude Code) Zugriff auf die Werkzeuge geben.

1. Die „Injektion“ von Wissen (Arnies Methode)

Wenn du ein neues Thema hast (z.B. ein Handbuch für SQL Server oder ein Transkript), nutzt du den Befehl im Terminal: claude "Lies die Datei Quelle.txt und ordne sie nach dem Karpathy-Standard in mein Wiki ein."

Claude wird dann:

• Die Datei lesen.

• Überlegen: „Gehört das zu einem Projekt? Ist das eine neue Entität?“

• Automatisch Dateien wie SQL_Server_Optimization.md im richtigen Ordner erstellen.

• Darin Links wie [[SQL Server 2022]] setzen.

2. Der Prompt für dein Projekt-Template

Da du dein eigenes Workspace Template hast, kombinieren wir den Karpathy-Ansatz mit deinem Workflow. Wenn du dein Template mit /start ausgefüllt hast, gib Claude diesen Befehl:

„Ich habe gerade ein neues Projekt mit meinem Standard-Template aufgesetzt (siehe Datei 10_Projects/MeinProjekt/Setup.md). Verarbeite dieses Projekt nach dem Karpathy-Standard: Erstelle im Wiki-Bereich Verknüpfungen zu den benötigten SQL-Techniken und lege die Projektschritte als atomare Aufgaben in meinem Index an.“

Zusammenfassung der Links & Tools für diesen Schritt:

• Der Original-Post von Karpathy: X (Twitter) Link – Hier beschreibt er, wie er Claude nutzt, um sein lokales Dateisystem als Wissensbasis zu „beleben“.

• Arnies „Agent-Prompt“: Arnie empfiehlt zusätzlich, in die Datei agent.md spezifische Coding-Regeln zu schreiben, falls du Claude auch zum Schreiben von SQL-Skripten innerhalb von Obsidian nutzt.

Der Karpathy-Standard-Prompt (Das Wiki-Protokoll)

Du bist ein KI-Wissens-Agent, der ein lokales Obsidian-Wiki verwaltet. Dein Ziel ist es, Informationen in einer hochgradig vernetzten, atomaren Struktur zu organisieren. Befolge strikt dieses Protokoll:

1. Atomisierung: Zerlege Informationen in die kleinstmöglichen sinnvollen Einheiten (Dateien). Erstelle keine riesigen Dokumente, sondern viele kleine, die untereinander verlinkt sind.

2. Ordner-Struktur:

• /Concepts: Definitionen, Techniken, Ideen (z. B. SQL-Indizierung.md).

• /Entities: Personen, Firmen, spezifische Hard- oder Software (z. B. AS400-Server.md, MN.md).

• /Sources: Originale Texte, Transkripte oder Web-Artikel. Jede Source-Datei muss oben einen Link zu den daraus extrahierten Concepts und Entities haben.

• /Index: Karten von Inhalten (MOCs), Logs und Projektübersichten.

3. Verlinkung (Backlinks): > Jede neue Datei muss mindestens einen Link [[Dateiname]] zu einer bestehenden Datei enthalten. Wenn du eine Datei über „Bremsen-Tuning“ erstellst, verlinke sie mit [[Cupra Tavascan]].

4. Metadaten: Jede Datei beginnt mit einem YAML-Header:

tags: [wiki/concept oder wiki/entity] created: YYYY-MM-DD

5. Arbeitsweise: Wenn ich dir Informationen gebe:

1. Suche im Vault, ob Begriffe bereits existieren.

2. Erstelle neue Dateien für unbekannte Entitäten/Konzepte.

3. Aktualisiere den Index/Log.md, um zu zeigen, was du heute gelernt hast.

4. Antworte nur mit: „Wiki aktualisiert: [Liste der geänderten Dateien]“.

Wie du diesen Prompt jetzt konkret einsetzt (Schritt-für-Schritt)

Da du dich mit Obsidian noch nicht auskennst, hier der Weg, wie dieser Prompt „lebendig“ wird:

1. Die Initialzündung: Öffne dein Terminal (PowerShell) in deinem Obsidian-Ordner.

2. Claude Code starten: Tippe claude und drücke Enter.

3. Den Prompt füttern: 

LLM Wiki
A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

The idea here is different. Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn't just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then kept current, not re-derived on every query.

This is the key difference: the wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The wiki keeps getting richer with every source you add and every question you ask.

You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work — the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time. In practice, I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time — following links, checking the graph view, reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

This can apply to a lot of different contexts. A few examples:

Personal: tracking your own goals, health, psychology, self-improvement — filing journal entries, articles, podcast notes, and building up a structured picture of yourself over time.
Research: going deep on a topic over weeks or months — reading papers, articles, reports, and incrementally building a comprehensive wiki with an evolving thesis.
Reading a book: filing each chapter as you go, building out pages for characters, themes, plot threads, and how they connect. By the end you have a rich companion wiki. Think of fan wikis like Tolkien Gateway — thousands of interlinked pages covering characters, places, events, languages, built by a community of volunteers over years. You could build something like that personally as you read, with the LLM doing all the cross-referencing and maintenance.
Business/team: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. Possibly with humans in the loop reviewing updates. The wiki stays current because the LLM does the maintenance that no one on the team wants to do.
Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives — anything where you're accumulating knowledge over time and want it organized rather than scattered.
Architecture
There are three layers:

Raw sources — your curated collection of source documents. Articles, papers, images, data files. These are immutable — the LLM reads from them but never modifies them. This is your source of truth.

The wiki — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.

The schema — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the wiki. This is the key configuration file — it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain.

Operations
Ingest. You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages. Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision. It's up to you to develop the workflow that fits your style and document it in the schema for future sessions.

Query. You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart (matplotlib), a canvas. The important insight: good answers can be filed back into the wiki as new pages. A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn't disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.

Lint. Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.

Indexing and logging
Two special files help the LLM (and you) navigate the wiki as it grows. They serve different purposes:

index.md is content-oriented. It's a catalog of everything in the wiki — each page listed with a link, a one-line summary, and optionally metadata like date or source count. Organized by category (entities, concepts, sources, etc.). The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.

log.md is chronological. It's an append-only record of what happened and when — ingests, queries, lint passes. A useful tip: if each entry starts with a consistent prefix (e.g. ## [2026-04-02] ingest | Article Title), the log becomes parseable with simple unix tools — grep "^## \[" log.md | tail -5 gives you the last 5 entries. The log gives you a timeline of the wiki's evolution and helps the LLM understand what's been done recently.

Optional: CLI tools
At some point you may want to build small tools that help the LLM operate on the wiki more efficiently. A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search. qmd is a good option: it's a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking, all on-device. It has both a CLI (so the LLM can shell out to it) and an MCP server (so the LLM can use it as a native tool). You could also build something simpler yourself — the LLM can help you vibe-code a naive search script as the need arises.

Tips and tricks
Obsidian Web Clipper is a browser extension that converts web articles to markdown. Very useful for quickly getting sources into your raw collection.
Download images locally. In Obsidian Settings → Files and links, set "Attachment folder path" to a fixed directory (e.g. raw/assets/). Then in Settings → Hotkeys, search for "Download" to find "Download attachments for current file" and bind it to a hotkey (e.g. Ctrl+Shift+D). After clipping an article, hit the hotkey and all images get downloaded to local disk. This is optional but useful — it lets the LLM view and reference images directly instead of relying on URLs that may break. Note that LLMs can't natively read markdown with inline images in one pass — the workaround is to have the LLM read the text first, then view some or all of the referenced images separately to gain additional context. It's a bit clunky but works well enough.
Obsidian's graph view is the best way to see the shape of your wiki — what's connected to what, which pages are hubs, which are orphans.
Marp is a markdown-based slide deck format. Obsidian has a plugin for it. Useful for generating presentations directly from wiki content.
Dataview is an Obsidian plugin that runs queries over page frontmatter. If your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts), Dataview can generate dynamic tables and lists.
The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free.
Why this works
The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.

The human's job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM's job is everything else.

The idea is related in spirit to Vannevar Bush's Memex (1945) — a personal, curated knowledge store with associative trails between documents. Bush's vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn't solve was who does the maintenance. The LLM handles that.

Note
This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice. Everything mentioned above is optional and modular — pick what's useful, ignore what isn't. For example: your sources might be text-only, so you don't need image handling at all. Your wiki might be small enough that the index file is all you need, no search engine required. You might not care about slide decks and just want markdown pages. You might want a completely different set of output formats. The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs. The document's only job is to communicate the pattern. Your LLM can figure out the rest.


Du bist jetzt mein LLM-Wiki-Agent. Setze diese exakte Ideendatei als mein zweites Gehirn um. Führe mich Schritt für Schritt durch: Erstelle die Schema-Datei CLAUDE.md mit allen Regeln, richte index.md und log.md ein, definiere Ordnerkonventionen und zeige mir das erste Ingest-Beispiel. Ab jetzt folgt jede Interaktion dem Schema.

4. Der erste Auftrag: Schreibe direkt danach:

„Hier ist mein erster Input: Ich arbeite mit SQL Server 2022 und einer AS400 als LinkedServer. Mein Name ist MN und ich fahre einen Cupra Tavascan VZ. Bitte richte mein Wiki basierend auf diesen Informationen ein.“

Was passiert dann in Obsidian?

Du wirst sehen, wie Claude im Hintergrund (in deinem Explorer links) plötzlich die Ordner Concepts, Entities und Index erstellt. Er wird Dateien anlegen wie:

• Entities/AS400.md

• Entities/Cupra_Tavascan_VZ.md

• Concepts/Linked_Server.md

Integration deines Workspace-Templates

Wenn du dein Template nutzt (kopieren in den Projektordner und /start), sagst du zu Claude einfach:

„Ich habe in 10_Projekte/NeuesDashboard/Setup.md mein Template ausgefüllt. Nutze den Wiki-Standard, um die dort genannten Aufgaben in mein System zu integrieren und Verknüpfungen zu meinen SQL-Notizen herzustellen.“

Zusammenfassung der Links (für dein Setup):

• Arnies Tool-Empfehlung (Codex/OpenClaw): Wenn du nicht das teure Claude-Abo willst, zeigt Arnie im Video, wie man „OpenClaw“ nutzt. Aber für den Start bleib bei Claude Code.

• Obsidian Clipper: Chrome Extension – Damit schickst du Webseiten direkt in deinen /Sources Ordner, damit Claude sie nach dem Karpathy-Standard verarbeiten kann.