I got tired of my Obsidian vault rotting, so I built an AI to maintain it. (Open-sourcing my LLM-Wiki)
At some point, I got incredibly frustrated with my own notes.
I had Obsidian vaults for five different ventures and client projects. Each one started strong and degraded within weeks. Notes became orphans. Cross-links rotted. The index was always out of date. I'd search for something I knew I'd written and find nothing—or three conflicting versions.
The standard productivity advice is "build a better system." I tried that. The real problem is that maintaining a knowledge base is administrative work that doesn't get done when you're busy building—which is all the time when you're running multiple things.
So I asked a different question: what if the LLM maintained it?
I recently saw Andrej Karpathy post a gist about the "LLM-Wiki" pattern—the idea of using a local AI to actively compile and manage a plain-text wiki. It was a brilliant baseline, so I took his method, integrated my own multi-venture workflows, and built a personal operating system out of it.
This isn't a chatbot that answers questions from outside your notes. It’s an agent that works inside the vault—ingesting sources, synthesising concept pages, maintaining cross-links, and running health checks. It operates via a plain-English schema that tells it exactly how the folder structure works and what to do with each workflow.
The result is LLM-Wiki. I've been using it locally as my daily driver, and it's the first setup that has actually stayed useful.
What it does
You give Claude Code a CLAUDE.md file at the vault root. It defines the folder structure, six core workflows, and a set of conventions (frontmatter, wikilinks, log format). When you open the terminal and run claude, it reads the schema and becomes the vault's maintainer.
Commands like "process the inbox", "promote this literature note", or "lint the vault" execute structured workflows. It creates literature notes from sources you feed it, synthesises them into permanent concept pages, and keeps an ops log of everything it touches.
Everything lives in plain Markdown you own. No proprietary format. No database. No sync subscription.
What I open-sourced today
The CLAUDE.md operating schema (the main thing — the pattern lives here)
9 note templates
6 worked examples (reading a book, watching a video, studying for a certification, ingesting a PDF, taking a course, reading tool docs)
A demo vault with a Deep Work concept page and a Cal Newport entity
Pre-configured .obsidian/ with Dataview + Templater registered
An optional Notion MCP sync skill for pushing actions out of the vault
It's MIT licensed, completely free, and there's no sign-up.
Honest limitations
It requires Claude Code (which runs on API credits, so it's not entirely free). It benefits from occasional human curation—it's a tool that amplifies your thinking, not a replacement for it. And it takes a session or two to get familiar with the workflow conventions.
Where this is going
I'm building other verticals on top of this open engine. The first is Founder OS—a calibrated, self-maintaining decision journal and operating system for founders (more details at founder-os.ozanyildirim.me). The engine stays open; the domain-specific skill packs and hosted layers are where the business goes.
I would love feedback from anyone who's tried to maintain a structured knowledge base over time. I'm curious to hear what broke for you and whether this pattern would solve it.
→ Vault Details: llm-wiki.ozanyildirim.me
→ GitHub: github.com/tyrozz/llm-wiki
→ The Karpathy gist that inspired the base architecture: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
The strongest part is that the agent works inside plain Markdown instead of becoming another knowledge silo. For founder workflows, I would make the first promised outcome very specific: keep the decision log, source notes, and current index in sync for one project.
That is the wedge I would trust before a broader "personal OS" promise. If it reliably prevents one vault from rotting for 30 days, the expansion path is obvious.
This is a brilliant piece of product positioning feedback, thank you.
You completely nailed the onboarding friction problem. Asking a busy founder to migrate their entire life into a 'Personal OS' on day one is a massive, unrealistic ask.
Your idea of the '30-day anti-rot wedge' for a single project is so much sharper. Pointing the AI at just one active client or codebase to automatically maintain the decision log (log.md), synthesize the source notes (1-Literature Notes/), and keep the index strictly synced proves the value with zero migration risk.
Really appreciate you taking the time to drop this insight.
This is a strong pattern because the pain is not “note-taking.” It is knowledge decay. Most people can capture information, but very few systems keep the structure alive after the first week.
The Founder OS direction is more interesting than the open-source vault itself, because that turns the engine from a useful personal workflow into a decision and operating layer for founders. If you push that angle, I’d make the positioning less about “LLM-Wiki” and more about a self-maintaining workspace that keeps decisions, research, notes, and operating context from drifting apart.
The naming is worth pressure-testing early though. LLM-Wiki is clear for the open-source engine, but it may box the bigger product into a technical/wiki frame when the real business layer sounds broader: founder workflow, decision memory, operating context, and AI-maintained knowledge infrastructure.
Xevoa .com would fit that direction well because it feels more like an AI workspace or operating layer than a wiki/tool name. If Founder OS becomes a hosted product with skill packs, workflows, and paid verticals, the brand shell probably needs to carry more than the current LLM-Wiki frame.
I’d separate the open engine name from the commercial product name before too many docs, examples, and early users lock onto the wrong category.