LLM Wiki Manager

A skill for running a personal LLM-managed wiki: a persistent, compounding markdown knowledge base where the human curates sources and asks questions, and the LLM does all the reading, writing, cross-referencing, and bookkeeping.

The pattern is intentionally tool-agnostic — it's just markdown files in a git repo. It works in any editor (Obsidian, VS Code, plain vim), and the skill makes no assumptions beyond "you have a filesystem and git". The user is on Claude Code.

The three layers (memorize this)

Every wiki this skill manages has exactly three layers. Confusing them is the most common failure mode.

1. raw/ — immutable sources the user curates. Articles, PDFs, transcripts, screenshots, data files. The LLM reads from raw/ but never modifies it. This is the source of truth; if it gets edited the audit trail breaks.
2. wiki/ — markdown pages the LLM owns entirely. Source summaries, entity pages, concept pages, comparisons. Three structural files always live here: wiki/index.md (content catalog), wiki/log.md (operation log), wiki/hot.md (~500-word hot cache, rewritten after every ingest). The user reads it; the LLM writes it. Pages link to each other and back to specific files in raw/.
3. CLAUDE.md (at the wiki root) — the schema. Tells future LLM sessions how this particular wiki is structured, what the page conventions are, how categories are named, how aggressive ingest should be. Co-evolved with the user over time — when something works, write it down here so the next session inherits it.

The whole point of the pattern is that wiki/ is a persistent, compounding artifact. It is not re-derived on every query. New sources update existing pages in place. That is what separates this from RAG.

Mode router

When this skill triggers, identify which mode applies and read the matching reference file. The user rarely names the mode explicitly — infer it from context. If genuinely ambiguous, ask one short clarifying question.

If multiple modes apply (e.g., user asks a question and wants the answer filed back), do them in sequence and log each one.

Update vs. Ingest's Disputes handling — important distinction. Ingest already handles contradictions on a single page by adding a Disputes section. Switch to Update mode only when the new source's claim affects multiple existing pages — that is, when the same idea is paraphrased across the wiki and a single Disputes section won't keep the wiki internally consistent. If only one page is affected, stay in ingest. See references/update-workflow.md for the precise trigger checklist.

Multi-wiki requires CLAUDE.md configuration. Before any multi-wiki operation, read the project CLAUDE.md for an ## External Wiki section that declares the global wiki path and routing rules. If the section is missing and a multi-wiki operation is requested, run Schema-evolve first to add it, then proceed. Never guess or assume the global wiki path. See references/multi-wiki-routing.md for the one-time setup block and the four canonical scenarios.

Core invariants (apply in every mode) — nine rules

These are the disciplines that make a wiki compound. Skipping them is how wikis rot.

1. The user owns raw/. The LLM owns wiki/.

Never write to raw/. Never ask the user to edit wiki/ by hand (they can if they want, but the skill never asks). When summarizing a source, the summary lives in wiki/sources/<source-slug>.md and links back to the file in raw/.

2. Every operation logs to wiki/log.md.

After any ingest, query, update, or lint, append a single entry using scripts/append_log.py --path <wiki-root>:

## [YYYY-MM-DD] ingest | <source title>
## [YYYY-MM-DD] query  | <one-line question>
## [YYYY-MM-DD] update | <claim corrected, source authority>
## [YYYY-MM-DD] lint   | <pages touched or "clean">

Consistent prefix matters — it makes the log greppable: grep "^## \[" wiki/log.md | tail -20 shows recent activity. The script enforces the format. For lint, the script auto-logs by default — you don't need a separate append_log.py call after running lint_wiki.py. For ingest/query/update, the LLM calls the script.

3. Every new or significantly-updated page touches wiki/index.md.

Use scripts/update_index.py --path <wiki-root>. The index is content-oriented: category, title, one-line summary, link. It is the LLM's primary navigation aid in future sessions when the wiki is large. Stale index = wiki that feels lost.

4. Cross-reference aggressively.

When ingesting a source about, say, a person who already has an entity page, update that entity page with the new information. Don't leave the connection implicit in the source summary. The whole value proposition is that connections are made eagerly, while context is fresh, not lazily at query time.

Use markdown wiki-style links: [Page Title](../entities/page-title.md) or, if the user prefers Obsidian-style, [[page-title]]. Pick one convention and record it in CLAUDE.md.

5. Cite back to raw/.

Every claim in a wiki page should be traceable to a specific source. The standard pattern in source-summary pages is:

> Quote or paraphrase from the source.
> — `raw/2026-01-pollan-eat-food.pdf`, p. 14

In synthesis pages (entity, concept, comparison), use inline references like (see [Pollan 2026](../sources/pollan-eat-food.md)). The reader should always be able to trace a claim back to a real source.

6. Flag contradictions, don't silently overwrite.

If a new source contradicts an existing claim on a wiki page, do not just replace the old claim. Add the new claim alongside, mark both with their source, and note the conflict — usually as a > [!warning] Sources disagree callout or a "Disputes" subsection. The user decides which to believe; the wiki records the disagreement.

7. Rewrite wiki/hot.md after every ingest.

wiki/hot.md is a ~500-word hot cache: vault state, the latest ingest, open work items, tag inventory. It is the first file a cross-project reader sees. Rewrite entirely — do not append. If the file doesn't exist yet, create it from assets/templates/hot.md.tmpl. See references/ingest-workflow.md Step 10 for the re