llm-wiki-skill: compiling raw sources into a cross-linked Markdown wiki

The problem is retrieval that forgets, not retrieval that misses

RAG re-fetches raw documents on every query. The README states the pattern this skill implements instead: the LLM compiles raw sources into a persistent, cross-linked Markdown wiki, and each compile, ingest, query, lint and audit pass makes that wiki richer. The distinction matters for a specific kind of work. If you are reading papers on one topic across weeks, or compiling journal entries into a personal encyclopedia, or feeding Slack threads and meeting notes into a team base, the value is in the accumulated structure, not in the retrieval step. A vector store answers the same question the same way on day one and day ninety. A wiki is supposed to answer it differently on day ninety because earlier passes added links, summaries and corrections.

The division of labour is explicit. You own sourcing raw material, asking questions, steering direction, and filing feedback on things the AI got wrong. The LLM owns all writing, cross-referencing, filing, bookkeeping, and acting on your feedback. That is a real commitment, not a slogan. If you are not willing to read what the agent wrote and file corrections, the wiki will drift and nothing in the repo prevents that drift. The lint script checks link and log shape, not whether a claim is true.

The intended users are people who already work inside an agent harness and treat Markdown as the storage layer. The README lists four use cases: research deep-dive, personal wiki, team knowledge base, and reading companion. All four assume you will keep the directory around for a long time and revisit it.

What the skill actually contains, and where the audit format lives

The repository has three parts that share one contract. The skill itself is a directory containing SKILL.md, which the agent reads, plus a references folder and a scripts folder. The references are five guides: schema-guide.md holds a CLAUDE.md schema template, article-guide.md covers article writing with divide and conquer, mermaid and KaTeX, log-guide.md defines a log folder convention, audit-guide.md documents the audit file format and processing workflow, and tooling-tips.md covers Obsidian, qmd, the plugin and the web viewer.

The scripts are Python, not TypeScript, despite the repository being reported as primarily TypeScript. scaffold.py bootstraps a new wiki directory. lint_wiki.py runs what the README calls a 7-pass health check covering links, audit and log shape. audit_review.py groups open and resolved audits by target. The TypeScript lives in audit-shared, a library with src files named schema, anchor, id, serialize and index.

That shared library is the load-bearing design decision. The Obsidian plugin and the web preview server both write audit files through it, and the README claims the result is byte-identical in shape whether a comment originated in the vault or the browser. That is the sort of claim you can verify cheaply by filing one comment from each surface and diffing the two files. If it holds, the audit folder is a single queue with two front ends, which is a better arrangement than two tools writing near-matching formats. If it does not hold, audit_review.py is the place the mismatch will surface.

Install, scaffold, ingest, lint: the commands the README gives

Installation is a copy. The README shows copying the skill directory to ~/.claude/skills/llm-wiki/ for Claude, or to ~/.codex/skills/llm-wiki/ for Codex, then referencing it in the agent config or pasting llm-wiki/SKILL.md directly into the agent context. There is no package to install for the skill itself and no version to pin, which matters given the experimental label.

The quick start is six steps. Scaffold with python3 llm-wiki/scripts/scaffold.py ~/my-wiki "My Research Topic". Add a source by copying a file into ~/my-wiki/raw/articles/. Tell the agent to ingest that path. Ask questions against the wiki. Run python3 llm-wiki/scripts/lint_wiki.py ~/my-wiki periodically. Then file a comment from the web viewer or the Obsidian plugin and run python3 llm-wiki/scripts/audit_review.py ~/my-wiki --open, followed by telling the agent to process the open comments.

The web viewer needs a build step first. From the repository root: cd audit-shared && npm install && npm run build, then cd web && npm install && npm run build. Start it with npm start -- --wiki "/path/to/your/wiki-root" --port 4175, and open http://127.0.0.1:4175. The two flags are --wiki and --port. The plugin build is similar: build audit-shared, then in plugins/obsidian-audit run npm install, npm run build, and npm run link -- "/path/to/your/Obsidian vault", then enable 'LLM Wiki Audit' under Settings, Community plugins.

Note the ordering constraint. audit-shared must be built before either front end, because both depend on it. Skipping that step is the most likely first failure.

The audit loop is the part with the most moving pieces

Most of the repository is Markdown conventions and a scaffold script. The audit loop is where the engineering sits, and it is also where the design is most opinionated. A comment is not a chat message. It is written into an audit folder as an anchored Markdown file, carrying a severity and a target. audit_review.py groups those files by target and can filter to open ones with --open. The agent then processes them.

Anchored comments in a document that the agent rewrites on every pass is a hard problem, and the anchor module in audit-shared is where the project has chosen to solve it. The README does not describe the anchoring strategy, the severity scale, or what happens when the text a comment was anchored to no longer exists. Those are the questions to ask before trusting the loop on a wiki you care about. A comment that silently loses its anchor is worse than no comment, because it looks like it was handled.

The severity field implies triage, but the README does not say whether severity affects processing order or whether the agent is expected to act on every comment. Without that, severity is a label the human applies and the agent may ignore. That is a gap worth testing on a small wiki before you rely on it.

The upside of the design is that feedback is durable and inspectable. An audit file is a file. You can grep it, diff it, and keep resolved ones as a record of what the agent got wrong. That is more than most agent feedback mechanisms offer, where a correction disappears into a conversation.

Where this is the wrong tool

The README labels the skill experimental and says it will iterate over time, and asks for feedback in GitHub issues. There are no releases retrieved for the repository, so there is no tagged version to pin and no changelog to read before upgrading. If you copy the skill into ~/.claude/skills/ or ~/.codex/skills/, your next pull from main changes agent behaviour with no version boundary. For a personal reading wiki that is fine. For a shared team knowledge base where two people depend on identical behaviour, it is a real operational risk you have to manage yourself, for example by vendoring a specific commit.

The pattern also fails when the corpus is large and changes fast. Compilation is a write-heavy operation that the LLM performs, and every pass adds to the wiki. A source set that turns over weekly, like a fast-moving vendor's documentation, will produce a wiki that is partly stale and partly current with no automatic way to tell which sections came from which source revision. The README does not describe incremental invalidation. RAG handles that case better precisely because it never commits to a stored summary.

Finally, the licence situation is worth stating plainly. The README's License section says MIT, but the repository metadata supplied here lists the licence as unknown. Those two disagree, and the README is the only place MIT appears. If you need certainty for a commercial deployment, confirm the licence file in the repository before you depend on it. This is not legal advice; it is a note that the two sources conflict.

How it differs from the other Karpathy-wiki implementations

The README points to three related projects, and the differences are structural rather than cosmetic. pedronauck/skills karpathy-kb is described as full Obsidian vault integration, which suggests the vault is the primary surface. Astro-Han/karpathy-llm-wiki is described as an example implementation, meaning it demonstrates the pattern rather than packaging it as a skill with tooling. qmd is semantic search for Markdown wikis, which is a different layer entirely: it helps you find things in a wiki, and does not build one.

llm-wiki-skill's distinguishing choice is that it ships two feedback surfaces plus the shared library that keeps them consistent, and it packages the whole thing as an agent skill with a SKILL.md entry point. That makes it the most tooling-heavy of the three, and also the one with the most surface area to maintain. If you only want the pattern, reading Karpathy's gist and writing your own SKILL.md is a smaller commitment. If you want the audit loop with a browser and a vault front end, this repo is the one that provides it.

Compared with a plain RAG pipeline, the difference is where the work happens. RAG spends compute per query and stores vectors. This spends compute per ingest and stores prose. That trade favours a corpus you revisit and disfavours a corpus you sample once. If your questions are broad and one-off, the compilation cost is wasted.

Maintenance cost and what to check first

Two build chains and three languages is the honest description. Python scripts handle scaffolding, linting and audit review. TypeScript in audit-shared is built with npm and consumed by both the Obsidian plugin and the web server. The web client is a vanilla-TS SPA with mermaid and a selection popover. Upgrading means rebuilding audit-shared first, then whichever front ends you use, and re-copying the skill directory if SKILL.md or the references changed. There is no single command in the README that does all of it.

The references folder is the part that will age fastest. schema-guide.md is a CLAUDE.md schema template, and the article conventions in article-guide.md govern how the agent writes. If you change the schema, existing articles do not migrate themselves, and lint_wiki.py checks link, audit and log shape rather than schema conformance. Budget for a manual pass after any schema change.

Before adopting, verify three things in this order. Run scaffold.py on a throwaway directory and read the generated tree, because that structure is what everything else assumes. Ingest two or three real sources and read the resulting articles against article-guide.md, because the writing conventions are the product. Then file one audit comment from the web viewer and one from the Obsidian plugin and diff the two files, because the byte-identical claim is the reason the shared library exists. If all three hold on your material, the skill is doing what it says. If the third one fails, audit_review.py will be grouping files that do not agree on shape, and that is the bug to report.

Editorial conclusion

Adopt it if you are already running OpenClaw or Codex and want a wiki that accumulates rather than a retrieval loop that restarts every question. Skip it if you need a stable file format today: the README calls the skill experimental, the audit schema is one person's design, and there are no releases to pin. Before committing, run scaffold.py on a throwaway directory, ingest two or three real sources, run lint_wiki.py, and check whether the generated article shape matches how you intend to read the wiki in six months.

Official sources

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