LLM Wiki — bootstrap & operate

The pattern (Karpathy, 2026): instead of re-reading raw documents on every question (RAG), the LLM compiles sources once into a persistent, interlinked markdown wiki and keeps it current. Three layers: immutable raw/ sources → LLM-maintained wiki/ pages → a CLAUDE.md schema that turns the agent into a disciplined maintainer. The wiki compounds: every ingest and every good answer makes it richer.

This skill has two branches. Decide which one applies before doing anything else:

• OPERATE — the target directory (or a directory the user points at) contains a CLAUDE.md whose first line is <!-- llm-wiki:v1 -->. The wiki already exists; your job is to run an operation on it.
• BOOTSTRAP — no such marker. Your job is to create a new wiki from scratch.

OPERATE (existing wiki)

This branch is deliberately thin, because each wiki's own CLAUDE.md is the single source of truth for how that wiki works — wikis evolve their rules independently, and this skill must not override them.

1. Locate the wiki root (the directory holding the marked CLAUDE.md). If several candidates exist or none is obvious, ask which one.
2. Read that CLAUDE.md in full, plus index.md. Do not skim: the schema defines page types, tags, and workflows you are about to execute.
3. Execute the requested operation (ingest, query, lint, interview update, restructure) exactly as that CLAUDE.md's workflow section describes — including its user-verification checkpoints and its index/log bookkeeping.
4. Where anything in this skill and the wiki's CLAUDE.md disagree, the wiki's CLAUDE.md wins.

Done when: the operation's own completion condition from the wiki's CLAUDE.md is met, and index.md + log.md reflect it.

BOOTSTRAP (new wiki)

Work through these steps in order. The user experience to aim for: a guided conversation that feels like a kickoff meeting with a good consultant, ending with a ready-to-use folder.

1. Target directory

Confirm where the wiki will live before interviewing — it anchors the whole session.

• Cowork / Claude Code: a folder the user can reach after the session (inside the shared workspace or a path they name). Propose <workspace>/<topic-slug>-wiki/ and confirm.
• No user-reachable filesystem (plain chat): build under a scratch directory and deliver a zip through the file-presentation tool at the end, telling the user to unzip it locally.

2. Kickoff interview

Read references/interview-guide.md and run the interview it describes. It is a co-design session, not a form: one theme at a time, propose-then-refine, "skip" always allowed. Two outputs, in this order:

1. A near-verbatim transcript saved to raw/interview/YYYY-MM-DD_kickoff.md (create the directory early; save before scaffolding so nothing is lost if the session dies).
2. A filled design summary (the interview guide ends with its exact shape).

If the topic matches one of the patterns in references/domain-archetypes.md, use that archetype as your opening proposal in the interview — users correct a concrete draft far faster than they answer blank questions.

3. Design approval

Show the design summary (page types, folder tree, epistemic tags, tracked quantities, language, caution & privacy rules) in one screen and get an explicit "yes" before creating files. This is the cheapest moment to change anything.

4. Scaffold

Create the structure by adapting the assets, not writing from scratch — they encode the pattern's hard-won rules (append-only histories, verification checkpoints, lint discipline):

• assets/CLAUDE.template.md → <wiki>/CLAUDE.md. Fill every {{UPPER_SNAKE}} token and resolve every <!-- ADAPT: ... --> comment (act on it, then delete the comment).
• assets/HOWTO.template.md → <wiki>/HOWTO.md, adapted to the user's environment.
• assets/templates/index.template.md / log.template.md / raw-README.template.md → index.md, log.md, raw/README.md, with the domain's sections and naming rules.
• assets/templates/{overview,entity,concept,source,report}.template.md → one _TEMPLATE.md per page-type directory under wiki/, renamed and re-sectioned for the domain (a "biomarker", a "paper", a "competitor" are all entities — but their sections differ). {{lower}} placeholders inside page templates are for the user/future agent and stay.
• Create the raw/ subfolders from the design, each covered by the naming rules in raw/README.md.
• Offer git init + first commit ("wiki initialized"). Skip silently if git is unavailable.

5. Seed content

The interview itself is the first source. Compile wiki/<overview page>.md from the transcript (every line tagged as user-stated, per the schema's tags), create stub pages for entities the user already named, update index.md, and append the bootstrap entry to log.md. If the user brought documents, offer to run the first ingest now — following the freshly written CLAUDE.md, verification checkpoint included, so the user sees the real workflow once while you're still around to adjust it.

6. Hand off

Print the final tree, then walk the user through HOWTO.md's quick-start in two or three sentences: where to drop files, the fresh-session phrase that resumes work ("ingest the new files in raw/ — follow CLAUDE.md", or just "ingest" when this skill is installed), and the lint cadence. Invite one round of adjustments while context is hot.

Done when: the tree exists in the confirmed location; CLAUDE.md starts with <!-- llm-wiki:v1 --> and contains zero {{UPPER_SNAKE}} tokens and zero ADAPT comments; every page-type directory has a _TEMPLATE.md; index.md, log.md, HOWTO.md and the overview page exist; the interview transcript is filed under raw/interview/.

Design principles (read once, they explain the templates' whys)

• raw/ is immutable. The wiki layer can always be rebuilt from it; the reverse is never true. Nothing the agent does may modify, rename, or delete raw files.
• Verification checkpoint on ingest. Extraction errors (OCR'd numbers, misread tables) compound silently once filed. Extracted data is shown to the user for confirmation before any page is updated — the template hard-codes this; keep it.
• Epistemic tags on every claim. What a source says, what the user said, what the agent concluded, and what the agent merely suggests are different kinds of truth. Blurring them is how wikis rot into confident fiction.
• Flag, don't smooth. Contradictions between sources are content, recorded in "Open questions" — not averaged away.
• Lint is scheduled, not optional. Field reports agree the #1 failure mode is drift: cross-references silently going stale. The generated HOWTO sets a cadence (every 3–4 ingests) so the user actually runs it.
• No derivative pages without new information. Filing good query answers compounds the wiki; re-packaging existing pages just slows every future search.
• Index-first retrieval. At personal scale (hundreds of pages), reading index.md and drilling in beats any embedding infrastructure. Suggest search tooling only if the wiki outgrows this.
• Domain caution where stakes are high. For medical, legal, financial and similar domains, the schema marks agent suggestions for professional verification. The wiki is decision support, and saying so in the schema keeps every future session honest about it.