Turn your markdown vault into a compounding knowledge wiki (Karpathy inspired). Six Claude agent skills - knowledge grows with every conversation. Works with Obsidian, Logseq, etc. or just folders on your local drive. GUI install, no terminal, no code.
AI Agentsagent-skillsclaudeclaude-aikarpathyknowledge-base
Installation
# Add to your Claude Code skills
git clone https://github.com/vanillaflava/llm-wiki-claude-skills
README.md
llm-wiki-claude-skills
Six Claude agent skills for building and maintaining a personal knowledge wiki using Markdown files, wikilinks, and filesystem access.
What this is
A set of installable skills for Claude that let an LLM agent incrementally build and maintain a structured, interlinked knowledge base on your local filesystem. You add sources; the agent reads, synthesises, and files them into wiki pages. You ask questions; the agent reads the wiki and answers with citations. The wiki compounds over time - each source and each good question makes it richer.
This is my personal implementation of the LLM wiki pattern (see below). It is not a product. It has no backend, no API, no cloud sync (unless you provide one), and no dependencies beyond Claude and filesystem access. Everything lives in Markdown files on your disk. If you can read .md files, you can use this in Obsidian, Logseq, VS Code, iA Writer, or a plain folder.
I targeted Claude because that's the platform I'm learning most with - the .skill packaging is Claude-specific. The underlying instructions are plain markdown though, and the pattern adapts easily to other models; Codex uses AGENTS.md for the same purpose, and the instructions would need only minor adaptation.
The skills are (hopefully) honest about what they are: structured instructions to a language model, not code. They are good at their job but not infallible. The wiki is only as good as the sources you feed it and the questions you ask.
This implementation grows out of my own history of working with Obsidian and learning LLM capabilities (and their restrictions!) over time. I started with local markdown files, downloading them, struggling with diffs, and generally being too lazy to do the bookkeeping needed to keep everything connected, coherent, and above all fresh. MCPs changed that game significantly for me, once I was able to add file system access. Now I could use LLM agents to read, write, and maintain notes directly on disk, without intermediaries. Editing was way faster now, bootstrapping new agents became a lot easier, but the discipline required to not keep drowning in hundreds semi-connected markdown files (plus their legacy versions) was still a drag.
What changed all this for me, was Andrej Karpathy's llm-wiki gist, which describes using an LLM to maintain a persistent, compounding wiki rather than doing one-shot RAG retrieval (and I had barely learned what that even was, before I read about the pattern). The core insight, that the wiki is a compiled artefact that gets richer with every source and query, rather than a pile of documents to retrieve from (which I had up to this point) is wholly Karpathy's and is well worth reading in full. And perhaps even just implementing yourself. I had never pushed anything to GitHub before this little project. I learned so much from just trying this out. It's a little shocking to me that a) I could just do this and b) how incredibly well this pattern actually works.
What I am adding to it is just my own preferences in workflow (while keeping the skills generic): packaging, configuration, a source-tracing convention, and a few architectural choices that emerged from real sustained use.
What I figured out along the way
| Aspect | The pattern (intentionally open-ended) | This implementation |
| ------------------ | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Raw sources | Immutable permanent store | Flat queue; moving to ingested/ is the commit - filesystem is the state |
| State tracking | log.md records what's processed | Presence in ingested/ is the record; log.md is audit-only (no reading of what has already been ingested, re-ingestion accidental or not works well enough) |
| Query compounding | "Good answers can be filed back" (noted as a tip) | /crystallize as a first-class operation - primary mechanism for accumulating chat knowledge, every long session, every major change, archiving a heavy chat -> it compounds and enriches the next bootstrap. |
| Session bootstrap | Schema document | The wiki and domain home pages are the bootstrap - the wiki is the persistent context |
| Configuration | Suggestions for structure | wiki-config.md read by all six skills; configure once |
| Source attribution | Not specified | source: frontmatter field traces each wiki page to its origin in ingested/. reliability: (high/medium/low, agent-assessed at ingest time) captures source trust. Pages from lower-confidence sources get a ## Pending Review section flagging specific claims to corroborate. |
| Page structure | Not specified | 13 vault-side templates (one per page type) deployed by wiki-config on init. Writing skills read the matching template when creating new pages. User-editable without touching skill code; changes take effect immediately for new pages. |
The most satisfying thing that emerged from looking at other implementations and attempting to build this myself was /crystallize. Karpathy observes that query answers are valuable and shouldn't disappear into chat history. This isn't about a fully automated self-maintaining archival machine either. He stresses that staying involved is important, asking questions and learning from the answers is the whole point. The LLM is the previously absent bookkeeper, the flagger of stale content, conflicting information and orphaned treasures in a sea of markdown. I had already been prompting summaries of heavy chats, and cycling them out for a fresh instance. Now distilling a long working session into a wiki page became the primary way my projects accumulate knowledge from conversations. Domain home pages (think wiki hubs) serve as structured session bootstraps - previously that context lived in manually written summaries. Now the wiki itself is the persistent context across sessions.
One thing worth knowing before you see it for the first time: the ## Pending Review section that appears on some ingested pages is not an error. It is a quality signal written by the ingest skill when a page is created from a single lower-confidence source - it flags specific claims that would benefit from a stronger source. When you have one, drop it in raw/ and re-ingest; the skill will update the trust assessment and remove the section if the gap is resolved.
The other thing I worked out, which took longer than it should have, is how to make session cycling actually comfortable. Agents lose their working memory. The context window fills, things slow down, and you start a fresh chat. Without the wiki, you spend the next twenty minutes re-explaining where you left off.
What I found is that there are three layers that work together to make this nearly seamless, and the wiki is only one of them.
The first layer is whatever your platform calls permanent instructions - Personal Preferences in Claude, system prompt elsewhere. These fire on every conversation automatically. They carry who you are: working style, preferences, hard constraints, tool habits. They do not change by domain.
The second layer is per-project or per-domain instructions - Claude calls these Project Instructions, and similar mechanisms exist on other providers. You attach them to a project and they inject automatically into every chat in that project. I use these to tell the agent which domain it's working in and to direct it to read the relevant domain home before doing anything else.
The third layer is the domain home itself. The agent reads it at session start and knows: what is being worked on, what was decided last session, what is open. No briefing required.
Together: the permanent instructions carry who you are. The project instructions say which domain and point to the home. The domain home carries where you left off. A fresh agent with an empty context window is equipped in the first minute.
This is, I think, the most underappreciated part of the pattern as applied to ongoing work rather than a one-shot task. The wiki is the memory that survives session cycling. The instruction layers are what put a fresh agent on the right track before it even reads the wiki. Both matter, and they are designed to work together.
The agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.
