llm-wiki-skill: Compiling a Personal Knowledge Base Instead of Re-Retrieving It

The problem is re-derivation, not retrieval

Most retrieval setups do the same work twice. You point an agent at a folder of PDFs and notes, it embeds or searches them, and every question starts from the raw documents again. Nothing accumulates. The README states the core distinction plainly: knowledge is compiled once and continuously maintained, rather than re-derived from source documents on every query. That is the whole pitch, and it is a real difference in shape. The output is a structured wiki with entity pages, topic pages and material summaries joined by [[bidirectional links]], not a vector index. The target user is someone who already lives in an AI CLI and wants their notes to grow into something navigable. The README addresses Chinese-speaking users directly, and several optional extractors target sources that matter in that context, including WeChat public accounts and Zhihu. If your material is English-only and already well organised, the compilation step buys you less.

Two entry points, one knowledge base format

The repository is a monorepo with two consumption modes that read and write the same knowledge base format. The first is the Skill, described as mature and stable: you hand the repository link to a supported agent and it installs itself. The second is the workbench under workbench/, a local, conversation-first application with the interactive graph built in. The README is explicit that the workbench is under development, currently aimed at developers via npm run dev, with a desktop application mentioned as a later step. Both modes share the graph engine in packages/graph-engine/. The Skill emits a self-contained offline HTML file; the workbench renders a graph view. Same engine, two exits. That sharing is the strongest architectural claim in the README, and it is also the part most likely to drift, because the two consumers have different failure tolerances. The README addresses this with a shared drawing policy: density, node display, label and relation budgets, stable skeleton and community hierarchy all come from one rule set, computed once per update. The older toolbox and early wash templates are described as retired. Sigma/Graphology is the primary rendering route, with DOM/SVG kept as a fallback, a comparison path and an exception net rather than a second main path.

What the ingest pipeline actually produces

The pipeline is two-step by design: analyse first, then generate. Long content goes through a chained two-step pass, short content takes a simplified route. A script validates the analysis output before generation, which the README frames as protection against weak models emitting incomplete data. Each claim in a generated page carries a confidence label drawn from four values: EXTRACTED, INFERRED, AMBIGUOUS and UNVERIFIED. That is a useful piece of discipline. It makes the difference between what a source said and what the model concluded visible at the page level, and it gives you a filter for review. Caching is handled with SHA256 deduplication, write-through updates and what the README calls a self-healing safety net, so a weaker model does not silently skip the cache. Material routing picks an extraction method from the URL domain. Core formats (PDF, Markdown, text, HTML, pasted plain text) are handled directly with no external dependency. Web articles, X/Twitter, WeChat, YouTube and Zhihu are optional extractors that must be enabled at install time, and the README notes they fall back to manual pasting when extraction fails. Xiaohongshu is manual paste only. There is also a SessionStart hook that injects knowledge base context at the start of each agent session, and a conversation crystallisation feature that turns a useful exchange into a wiki page.

Install commands and the optional adapter flag

Installation is one shell script with a platform flag. The README gives four invocations: bash install.sh --platform claude, bash install.sh --platform codex, bash install.sh --platform openclaw, and bash install.sh --platform hermes. Each platform has its own entry document in the repository, at platforms/claude/CLAUDE.md, platforms/codex/AGENTS.md, platforms/openclaw/README.md and platforms/hermes/README.md. Optional extractors are opt-in and require an extra flag: bash install.sh --platform claude --with-optional-adapters. The README states that the default install prepares only the knowledge base mainline, and that web, X, WeChat, YouTube and Zhihu are enabled explicitly on demand. After installation you drive it in natural language inside the agent, for example asking it to initialise a knowledge base or to digest a given link. A purpose.md file at the knowledge base root steers how the agent organises and queries. Claude Code installations also get an /llm-wiki-upgrade command for in-place upgrades. That is the whole surface described in the material. There is no configuration reference for the graph output, no documented schema for the wiki pages, and no stated Node version requirement for the workbench beyond the npm run dev entry point.

The privacy boundary is stated, and it is narrow

The README draws a line and it is worth reading carefully. Knowledge base files and the offline graph artefacts stay on the local machine. But when you ask the agent to answer, digest or generate content, the prompt, the selected citations, the retrieved fragments, the tool output and the generated artefacts may be sent to whichever model provider you configured. API keys are not written into llm-wiki's own configuration. Third-party Skills only run as trusted local code after being explicitly installed and enabled. That is an honest description of where the boundary sits, and it is narrower than the phrase local knowledge base might suggest. The compilation step, which is the product's central mechanism, is exactly the step that ships your material to a provider. For a personal notes archive this is probably acceptable. For anything under a confidentiality obligation, the design means the sensitive content leaves the machine at ingest time, not merely at query time, which is a different risk profile from a purely local search tool. The material does not describe a local-model path for ingestion.

Where the design strains: graph identity and rename

The graph is the most developed part of the README and also the part that shows the most scar tissue. Pages with the same name are kept distinct by their relative path inside the knowledge base. Ambiguous links are not guessed: duplicated identifiers, broken links, pages pending creation, irregular paths and portability conflicts are collected and surfaced as warnings rather than resolved silently. Warning details are read-only and loaded per page. Invalid details do not leak absolute local paths into the offline file. Renaming is restricted to same-directory moves, initiated from a handleable warning or from the page reading area, with a full preview of automatic updates, read-only references, pinned positions and all ambiguities before anything is written. External edits, crashes and pending graph updates each have a defined recovery or retry path. This is a lot of machinery for what sounds like a simple operation, and it tells you the underlying model, files on disk plus a derived graph, has real edges. The failure mode to expect is not a crash. It is a rename or a move performed outside the tool that leaves the graph referencing a path that no longer exists, which then appears as a warning you have to work through. The README also notes that when the shared result fails, both the workbench and the offline graph clear old content and show an explicit message, and only a Sigma-specific failure falls back to DOM/SVG, so you are not left with a half-interactive graph. That is a deliberate choice to fail visibly rather than partially.

Alternatives, and the difference that matters

The obvious comparison is Obsidian. Both produce a folder of Markdown files with [[wikilinks]] and a graph view, and both keep the files on your machine. The difference is who does the writing. Obsidian is an editor with a graph; you create the pages, and plugins can assist. llm-wiki-skill is an agent Skill that creates the pages from source material, validates the analysis before generation, and labels each claim with a confidence value. Its graph is a generated artefact, a self-contained HTML file you double-click, not a live view over an open vault. The second comparison is a retrieval-augmented pipeline over the same folder, for example an embedding index plus a chat front end. That approach answers questions without changing the corpus. llm-wiki-skill changes the corpus: digesting a source produces new pages that persist and interlink, and the confidence labels record how each statement got there. The cost is that ingestion is a write operation with a review burden, and the benefit is that the tenth question about a topic starts from a page rather than from raw documents. If you want answers without curation, the retrieval pipeline is the better fit. If you want the curation to be the point, this is the shape you want.

Maintenance cost and an unresolved licence question

The README displays an MIT badge and links to a LICENSE file, but the repository metadata supplied here lists the licence as unknown. Treat that as a discrepancy to resolve before you build on it: open the LICENSE file in the repository and read it. The material does not state a licence identifier beyond the badge. On maintenance, the picture is mixed. There are no releases, so the upgrade path is the install script and, on Claude Code, the /llm-wiki-upgrade command rather than versioned artefacts. The version badge in the README reads v3.6.91 with the label graph safe rename and recovery, and the last push is dated 2026-07-27, so the project is active. The maintenance burden that falls on you is the knowledge base itself: every rename, every move and every externally edited page is a potential warning to clear, and the README's own emphasis on recovery paths suggests those warnings accumulate if you ignore them. The workbench adds a second surface, npm run dev, with a documented quality check that runs privacy, front-end and back-end, shared rules, graph, boundary, types, lint and build checks in sequence and validates startup and entry counterexamples in an isolated environment. That is a heavier contributor workflow than a typical notes tool. If you only want the Skill, the workbench is optional, and the README treats it as a separate, unfinished product.

Editorial conclusion

Adopt the Skill form if you already work inside Claude Code, Codex, OpenClaw or Hermes and want a local, file-based wiki that an agent maintains for you. Do not adopt it if you need a hosted, multi-user knowledge service, or if you want a stable API surface: the repository has no releases, the licence is not stated in the material supplied, and the workbench is explicitly marked as in development. Verify three things before committing: the actual LICENSE file, whether the optional extractors you need (web, X, WeChat, YouTube, Zhihu) install cleanly on your platform, and whether the graph HTML opens correctly from a local file path rather than a server.

Official sources

1. Issues
2. README
3. sdyckjq-lab/llm-wiki-skill on GitHub