pi-llm-wiki: A Personal Wiki Layer That Sits Between Raw Sources and an LLM
Self-maintaining, Obsidian-compatible knowledge base for pi — turn raw sources into an interlinked wiki that compounds. Native Open Knowledge Format (OKF) v0.2.
At a glance
- What is it?
- pi-llm-wiki is a TypeScript extension for the pi coding agent that turns URLs, PDFs and pasted text into an Obsidian-compatible vault of interlinked pages, with an MCP server for other clients. The interesting design choice is that it keeps raw captures immutable and puts synthesis in a separate, regenerable layer.
- Who is it for?
- Adopt pi-llm-wiki if you already run pi or oh-my-pi and want durable, greppable notes rather than per-question retrieval, and if you are willing to keep the vault in a directory you back up yourself. Skip it if you need a hosted service, a multi-user knowledge base, or if your sources are mostly web pages that change weekly, because the README does not describe a re-capture or diff workflow for pages that no longer match their source packet.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is that retrieval is ephemeral and note-taking is manual
The README frames the target problem directly: most file-based LLM workflows behave like one-shot RAG, where the model searches raw documents every time you ask a question and the synthesis disappears when the session ends. pi-llm-wiki inserts a middle layer between the raw input and the answer. The stated audience is someone who runs the pi coding agent (or oh-my-pi, which uses the same extension) and wants their reading to accumulate instead of being re-derived. The README also cites Andrej Karpathy's LLM Wiki pattern as the design reference, which tells you the intended shape: a wiki the model maintains, not a folder of documents the model happens to read. If you already keep notes in Obsidian and want an agent to file into that vault rather than beside it, this is the case it is built for. If your questions are answered fine by searching a corpus each time, the extra layer is overhead.
Four layers, and only two of them are meant to be edited
The architecture described in the README separates four kinds of artifact. Raw source packets preserve the source-of-truth inputs. Source pages summarize what each source says. Canonical wiki pages track what the wiki currently believes. Generated metadata keeps everything searchable and navigable. The README states that the tool blocks direct edits to raw sources and generated metadata, so the guardrail is enforced rather than advisory. That split matters because it decides what happens when the model gets something wrong: you correct the canonical page or add a new source, and the source packet stays as the record of what was actually captured. The page types the tools create are named in the README as concept, entity, synthesis and analysis pages, with wiki_ensure_page described as resolving or safely creating them. The generated registry is what wiki_search queries, and wiki_lint runs deterministic checks for orphans, broken links, duplicate aliases, coverage gaps and stale captures. Nothing in the supplied material describes an embedding index or a vector store, so the retrieval model here is keyword lookup over generated files, not similarity search.
Getting it running under pi or oh-my-pi
Installation is one command per host. For pi, the README gives pi install npm:@zosmaai/pi-llm-wiki. For oh-my-pi, it gives omp install @zosmaai/pi-llm-wiki. The README states that both hosts load the same extension, skill and /wiki-* slash commands. The documented first-run sequence is /wiki-init "AI Engineering", then /wiki-ingest, then /wiki-query What are the key patterns? The README also says the extension will proactively suggest creating a wiki on your first session, so the init step is not strictly manual. Underneath those commands are named tools: wiki_bootstrap initializes a vault with config, templates, schema and metadata; wiki_capture_source takes a URL, local file or pasted text; wiki_ingest batch-processes uningested packets; wiki_recall searches both the personal and project vaults; wiki_retro saves an atomic insight as a single markdown file; wiki_status reports counts and source states; wiki_watch prints a crontab line that runs the full cycle on a schedule. One environment variable appears in the README: WIKI_MARKITDOWN_TIMEOUT_MS, which sets the MarkItDown timeout for PDF extraction. That implies MarkItDown is an external dependency for PDFs, and the README does not describe what happens when it is absent or times out.
Two vaults, one search: how personal and project knowledge resolve
The README describes an always-on fallback vault at ~/.llm-wiki/ and a project vault at .llm-wiki/. wiki_recall is documented as searching both, deduplicated, so an insight captured while working on one repository can surface in another. This is the part of the design with the clearest practical consequence. It means the tool's memory is not scoped to a checkout, which is useful if you move between projects and want your notes to follow you. It also means the personal vault grows without a project boundary, and the README does not describe a per-project exclusion or a way to mark an entry as private to one context. The linting surface is where that shows up: stale captures and coverage gaps are reported by wiki_lint, but the supplied material does not say whether the lint distinguishes the two vaults when it reports them. If you plan to use this across client work, that is the first thing to check in practice.
OKF v0.2 output and the MCP server are the interoperability bet
The project describes itself as native to Open Knowledge Format v0.2. Concretely, the README says it creates portable OKF v0.2 documents with canonical frontmatter, standard Markdown links and stable source citations, and that it reads both legacy and OKF pages so existing vaults keep working without an automatic migration or rewrite. Indexes and logs are described as deterministic projections from authoritative pages, which is a claim about reproducibility rather than a feature you interact with. The second interoperability path is the MCP server: the README states the same OKF-aware wiki is available from Claude Code, Cursor and Windsurf over stdio MCP transport. The honest reading is that the format work is what makes the MCP path meaningful, because a client that connects over MCP still reads and writes the same files on disk. The README links a specification document at docs/superpowers/specs/2026-08-02-okf-foundation-design.md for implementation details; that file is where the frontmatter contract would be defined, and it is not reproduced in the material available here.
Trajectory capture is opt-in, and that is the right default
One feature is off by default: agent working memory. The README describes wiki_capture_trajectory as recording how a task was solved, meaning the tool-call trajectory, then distilling it into reusable skill or case pages, with wiki_recall_skill surfacing them later. It is enabled with /wiki-trajectories on. Keeping it off by default is defensible because trajectories are verbose and capture more than the user may intend to store, including the intermediate steps that did not work. The README does not describe a retention policy, a redaction step, or a size limit for trajectory data, and it does not say whether trajectories land in the personal vault or the project vault. If you turn this on, those are the questions to answer before the vault fills up. The feature is also the one most dependent on the host, since the trajectory is a record of tool calls made by pi or oh-my-pi, and the README does not state how it behaves under the MCP clients.
Where a plain Obsidian vault or a RAG pipeline wins
The comparison the README itself sets up is against one-shot RAG, and the difference is where synthesis lives. A RAG pipeline re-derives an answer from raw chunks on every query and stores nothing durable; pi-llm-wiki writes a page and keeps it, so the second question about the same topic reads a page instead of re-reading sources. The cost is that the wiki can be wrong in a way RAG cannot, because a stale canonical page persists until something flags it. wiki_lint is the stated mechanism for that, checking stale captures among other conditions, but the README does not describe how staleness is determined for a source that has changed at its URL. Against a plain Obsidian vault, the difference is authorship: Obsidian gives you linking and search but no ingestion, no page generation and no lint pass, and you write every note. pi-llm-wiki is the version where the agent files the notes and you review them. If you want a human-curated vault with no generated content in it, the plain vault is the better tool and the guardrails here would only get in the way.
Maintenance cost, licence, and what the release history suggests
The licence is MIT, which permits commercial use and modification provided the copyright notice and permission notice are retained; that is a summary of the standard MIT terms and not legal advice. The repository is TypeScript with Vitest, Biome, Codecov and CodeQL referenced in the README badges, and the README states 562 tests at 85.09 percent coverage. Those are the project's own numbers and they describe its test suite, not the reliability of your vault. The release history shows v0.12.1 on 2026-09-04, v0.12.0 two days earlier, and v0.11.8 on 2026-09-01, so the version is still moving in small increments and the last push recorded is 2026-09-10. The upgrade cost that follows from that cadence is the format question: the README promises dual-read compatibility for legacy and OKF pages, so an upgrade should not force a rewrite, but the promise is about reading, and the supplied material does not describe what happens to pages written by an older version when a newer one regenerates the indexes. For a personal vault that is a backup question. For a shared one it is a coordination question, and the README does not describe multi-user behaviour at all.
Editorial conclusion
Adopt pi-llm-wiki if you already run pi or oh-my-pi and want durable, greppable notes rather than per-question retrieval, and if you are willing to keep the vault in a directory you back up yourself. Skip it if you need a hosted service, a multi-user knowledge base, or if your sources are mostly web pages that change weekly, because the README does not describe a re-capture or diff workflow for pages that no longer match their source packet. Before installing, verify three things: which vault the tool resolves to in your working directory (the README says it searches both ~/.llm-wiki/ and .llm-wiki/), whether trajectory capture is still off by default in the version you install, and whether MarkItDown is present on the machine, since PDF extraction depends on it.
Community notes