burakolgun/vault-anything
3 stars · Last commit 2026-06-01
Generate Obsidian LLM wikis from source code and static docs — a Claude Code plugin.
README preview
# vault-anything Generate Obsidian LLM wikis from source code and static documents. A Claude Code plugin that reads a codebase (and optionally accompanying meeting notes, PRDs, ADRs), then produces a self-contained Obsidian vault. Inspired by Andrej Karpathy's idea of a "wiki for LLMs": every page is independently readable, prose-based, and richly cross-linked so it works equally well as human documentation or as LLM context. ## Why? Codebases are hard for LLMs to navigate as raw files, and hard for humans to onboard into. vault-anything sits in between: it processes the project once, distills it into prose wiki pages with wikilinks, and produces an Obsidian vault that works as either documentation or LLM context. ## How It Works The plugin maintains two layers in a workspace directory (default: `<project>/vault-anything/`): - **`raw/`** — staging area. The plugin writes per-file summaries here, and you can drop static documents (meeting notes, PRDs, ADRs) into numbered folders alongside. - **`vault/`** — the finished Obsidian wiki. Self-contained prose pages, wikilink-connected, Obsidian-ready. A single command (`/vault-anything:vault`) runs the full pipeline. Optional manual step: drop static documents into `raw/` before running, and they will be included in the generated pages. The generated vault is organized into a handful of categories: architecture concepts, cross-cutting concerns, and reference pages for the most important files, plus a set of **single-page indexes** that each capture one structural surface of the project — its API endpoints, messaging topics, configuration, data model, external integrations, scheduled jobs, and authorization permissions. Each index folds many entities into one scannable page rather than emitting a thin page per entity. These index pages become natural cross-service bridges when you run vault-anything across multiple related projects — a queue one service publishes to and another consumes from, or an endpoint one service exposes and another calls, ends up as a single wikilink hub.