llm-wiki

LLM Wiki — Knowledge Distillation Pattern

You are maintaining a persistent, compounding knowledge base. The wiki is not a chatbot — it is a compiled artifact where knowledge is distilled once and kept current, not re-derived on every query.

Three-Layer Architecture

Layer 1: Raw Sources (immutable)

The user's original documents — articles, papers, notes, PDFs, conversation logs, bookmarks, and images (screenshots, whiteboard photos, diagrams, slide captures). These are never modified by the system. They live wherever the user keeps them (configured via OBSIDIAN_SOURCES_DIR in .env). Images are first-class sources: the ingest skills read them via the Read tool's vision support and treat their interpreted content as inferred unless it's verbatim transcribed text. Image ingestion requires a vision-capable model — models without vision support should skip image sources and report which files were skipped.

Think of raw sources as the "source code" — authoritative but hard to query directly.

Don't confuse this with the in-vault _raw/ staging folder, which is a different thing: a scratch inbox for quick captures and drafts awaiting promotion (see wiki-capture and wiki-ingest). Files there aren't Layer 1 sources, but wiki-ingest still moves rather than deletes them on promotion, since some have no other copy.

Layer 2: The Wiki (LLM-maintained)

A collection of interconnected Obsidian-compatible markdown files organized by category. This is the compiled knowledge — synthesized, cross-referenced, and navigable. Each page has:

• YAML frontmatter (title, category, tags, sources, timestamps)
• Obsidian [[wikilinks]] connecting related concepts
• Clear provenance — every claim traces back to a source

The wiki lives at the path configured via OBSIDIAN_VAULT_PATH in .env.

Layer 3: The Schema (this skill + config)

The rules governing how the wiki is structured — categories, conventions, page templates, and operational workflows. The schema tells the LLM how to maintain the wiki.

Wiki Organization

The vault has two levels of structure: categories (what kind of knowledge) and projects (where the knowledge came from).

Categories

Organize pages into these default categories (customizable in .env):

Projects

Knowledge often belongs to a specific project. The projects/ directory mirrors this:

$OBSIDIAN_VAULT_PATH/
├── projects/
│   ├── my-project/
│   │   ├── my-project.md      ← project overview (named after project)
│   │   ├── concepts/          ← project-scoped category pages
│   │   ├── skills/
│   │   └── ...
│   ├── another-project/
│   │   └── ...
│   └── side-project/
│       └── ...
├── concepts/                   ← global (cross-project) knowledge
├── entities/
├── skills/
└── ...

When knowledge is project-specific (a debugging technique that only applies to one codebase, a project-specific architecture decision), put it under projects/<project-name>/<category>/.

When knowledge is general (a concept like "React Server Components", a person like "Andrej Karpathy", a widely applicable skill), put it in the global category directory.

Cross-referencing: Project pages should [[wikilink]] to global pages and vice versa. A project's overview page should link to the key concept, skill, and entity pages relevant to that project — whether they live under the project or globally.

Naming rule: The project overview file must be named <project-name>.md, not _project.md. Obsidian's graph view uses the filename as the node label — _project.md makes every project appear as _project in the graph, making it unreadable. So projects/my-project/my-project.md, projects/another-project/another-project.md, etc.

Each project directory has an overview page structured like this:

---
title: My Project

Special Files

Every wiki has these files at its root:

index.md

A content-oriented catalog organized by category. Each entry has a one-line summary and tags. Rebuild this after every ingest operation. Format:

Format rule: Add a space after the opening ( and tags. ❌ Don't: description (#tag) — breaks tag parsing ✅ Do: description ( #tag) — proper spacing and tag parsing

log.md

Chronological append-only record tracking every operation. Each entry is parseable:

.manifest.json

Tracks every source file that has been ingested — path, timestamps, what wiki pages it produced. This is the backbone of the delta system. See the wiki-status skill for the full schema.

The manifest enables:

• Delta computation — what's new or modified since last ingest
• Append mode — only process the delta, not everything
• Audit — which source produced which wiki page
• Staleness detection — source changed but wiki page hasn't been updated

Canonical source keys. Source keys MUST be stored in a single canonical form: absolute paths with ~ and env vars expanded (e.g. /Users/me/.claude/projects/.../abc.jsonl, never ~/.claude/...). The manifest is keyed by the raw string, so a mix of ~-relative and absolute keys lets the same file be tracked twice — and the delta check then re-ingests an already-processed file because the lookup misses the other-form key. Always expand before you compare against the manifest and before you write a new entry. To repair an existing vault that already has both forms, run scripts/manifest.py normalize <vault> (merges colliding entries, keeps the newest ingested_at).

Recording provenance. When you write a manifest entry, populate pages_created and pages_updated with the vault-relative page paths that source contributed to. This is what makes re-ingestion (when a source changes) able to find the pages to revisit, instead of guessing.

Page Template

When creating a new wiki page, use this structure:

Paper Deep-Dive Template

The generic template suits most sources. Academic papers are the exception. For ML/AI/LLM/VLM (and similar) papers landing in references/, the substance lives in the architecture, the equations, and the results table — exactly what a terse "Key Ideas" list flattens away. For these, use the richer template below. This is the one place where "compile, don't retrieve" yields to a thorough, self-contained walkthrough a reader could study instead of the paper.

Obsidian renders the needed primitives natively, so no extra tooling is required: Mermaid fenced diagrams, $$…$$ LaTeX (MathJax), markdown tables, and ![[image]] / ![[paper.pdf#page=N]] embeds.

Use this template only when the source is an academic paper (arXiv/conference) with load-bearing figures or equations. Everything else uses the generic Page Template above. Frontmatter, provenance markers, confidence, lifecycle, and relationships: are unchanged — only the body sections differ.

A Mermaid diagram reconstructed from the paper's prose is a synthesis, not a transcription — treat it as ^[inferred] when the interpretation is non-trivial.

Provenance Markers

Every claim on a wiki page has one of three provenance states. Mark them inline so the reader (and future ingest passes) can tell signal from synthesis.

Example:

Why this syntax:

• ^[...] is footnote-adjacent in Obsidian — renders cleanly and never collides with [[wikilinks]].
• Inline (suffix) so a single bullet stays a single bullet.
• Default = extracted means existing pages without markers stay valid.

Frontmatter summary: Optionally surface the rough mix at the page level so the user can scan for speculation-heavy pages without reading them:

These are best-effort numbers written by the ingest skill at create/update time. wiki-lint recomputes them and flags drift. The block is optional — pages without it are treated as fully extracted by convention.

Typed Relationships

Plain [[wikilinks]] in page bodies carry no semantic weight — they indicate "related to" but not how. The optional relationships: frontmatter block adds typed, directional edges to the knowledge graph.

The relationships: block

Each entry has two required fields:

• target — a wikilink (using the same format as OBSIDIAN_LINK_FORMAT) to the related page
• type — one of the allowed semantic types below

Allowed relationship types

Rules

• Optional field — omit the block entirely if no typed relationships are known. Untagged wikilinks remain valid and are treated as related_to by wiki-export.
• Don't duplicate — if [[foo]] already appears as an inline wikilink, the relationships: entry just enriches it with a type; it is not a second link.
• Direction matters — the page declaring the entry is the source; target is the destination. Only declare relationships from this page's perspective.
• Don't fabricate — only add a typed entry when the source material makes the relationship direction and type clear. When in doubt, use related_to or omit.

Skills that read relationships:: wiki-export (emits typed edges), cross-linker (writes typed entries when inferring links), wiki-query (surfaces type in answers and walks the typed-edge graph for multi-hop "how is X connected to Y" path queries — bounded BFS over the relationships: adjacency, frontmatter-only).

Confidence and Lifecycle

Every page carries two orthogonal trust signals plus an optional supersession link.

Required fields

lifecycle_reason and superseded_by are optional. Never fabricate them.

Confidence formula

The formula is a manual base score, not a deterministic URL classifier:

After calculating the raw score, assess whether the evidence covers the page's material claims. Partial coverage may justify keeping or lowering the score; unsupported material claims require source/claim repair before any confidence change. Avoid small score churn without meaningful epistemic change.

Source-quality scores (use the highest-matching bucket):

An independent evidence lineage is an origin that can corroborate a claim independently. Canonical source IDs remain useful for identity, but identity alone does not prove independence. Collapse dependent evidence before counting:

• files, releases, and commits from one repository → one repository lineage;
• retry/review/fix tasks in one workstream → one task lineage;
• parent/child Kanban records → one task lineage;
• byte-identical memories across profiles → one memory lineage;
• a snapshot plus the mutable source it captures → one lineage;
• aliases or metadata references resolving to one origin → one lineage.

The deterministic wiki-lint path validates _meta/trust-ledger.json; it does not recompute confidence from source strings. New or materially changed pages are marked for manual review. Refresh the ledger only after explicit human approval.

Per-skill defaults (ingest skills compute this automatically):

Lifecycle state machine

Five states. stale is not a state — it is a computed overlay: is_stale = (today − updated) > 90 days.

Only ingest skills set draft. All other transitions require a human editor. Update lifecycle_changed whenever the state changes.

Importance Tiering

The tier: field controls which pages get updated on each ingest pass and their priority in retrieval. As wikis grow, re-reading every page on every ingest wastes tokens — tiering lets ingest and query skills focus effort where it matters most.

Three tiers

Assignment rules

• New pages: default to tier: supporting
• Promote to core: when a page accumulates ≥5 incoming wikilinks or is flagged as a bridge by wiki-status insights mode
• Demote to peripheral: when a page has ≤1 incoming link and hasn't been updated in 90+ days
• Human override always wins — edit tier: manually to lock a page at any level
• Existing pages without tier: are treated as supporting (backward compatible — no migration needed)

Who manages tier

• wiki-ingest reads tier: to decide whether to update a page on the current pass
• wiki-query uses tier: to order candidates in the index pass and trim to context budget
• wiki-status insights mode computes graph metrics and suggests tier assignments — it never writes them automatically
• wiki-lint flags missing tier: on newly created pages (Phase 2 enforcement, same timeline as base_confidence)

Retrieval Primitives

Reading the vault is the dominant cost of every read-side skill. Use the cheapest primitive that can answer the question and escalate only when the cheaper one is insufficient. Any skill that needs content from the vault should follow this table rather than jumping straight to full-page reads.

Search command preference: for shell/file searches, use ripgrep (rg, rg --files) when available; if not, fall back to grep/find. Capitalized Grep/Glob names in these skills are tool-generic primitives for agents that expose those tools.

The rule: escalate only when the cheaper primitive can't answer the question. If you can answer from summary: fields alone, don't read page bodies. If a grepped section with -A 10 -B 2 gives you the claim, don't read the whole page. A 500-line page opened to read 15 lines is 485 lines of wasted tokens.

Why this matters: a 20-page vault lets you get away with full-vault scans. A 200-page vault does not. The primitives above are how the skills framework scales to large vaults without a database.

Skills that consume this table: wiki-query, cross-linker, wiki-lint, wiki-status (insights mode). Any new skill that reads the vault should cite this section rather than reinvent the pattern.

QMD Index Freshness

QMD is an optional search index layered on top of the vault. The markdown vault is the source of truth. Any skill that writes wiki markdown should refresh QMD after the vault write completes, but only when QMD_WIKI_COLLECTION is configured and the local QMD transport is available. If QMD refresh fails, keep the vault changes and report the QMD status separately.

Use the cheapest verification path that proves the new content is visible: qmd update, qmd embed only if vectors are stale or missing, then a targeted qmd get or qmd ls check for one written page or the collection root. Read-only skills should not refresh QMD.

Core Principles

1. Compile, don't retrieve. The wiki is pre-compiled knowledge. When you ingest a source, update every relevant page — don't just create a summary of the source.

2. Compound over time. Each ingest should make the wiki smarter, not just bigger. Merge new information into existing pages, resolve contradictions, strengthen cross-references.

3. Provenance matters. Every claim should trace to a source. When updating a page, note which source prompted the update.

4. Mark inferences. Default sentences are extracted. Mark synthesized claims with ^[inferred] and contested claims with ^[ambiguous]. A wiki that hides its guessing rots silently; one that marks it stays trustworthy.

5. Human curates, LLM maintains. The human decides what sources to add and what questions to ask. The LLM handles the bookkeeping — updating cross-references, maintaining consistency, noting contradictions.

6. Obsidian is the IDE. The user browses and explores the wiki in Obsidian. Everything must be valid Obsidian markdown with working wikilinks.

Link Format

All internal links connecting wiki pages are controlled by OBSIDIAN_LINK_FORMAT from the resolved config (default: wikilink).

Generating markdown-format links

When OBSIDIAN_LINK_FORMAT=markdown:

1. Compute the path from the current file's directory to the target .md file using .. to climb up as needed.
2. Use the page title or a natural phrase as display text.
3. Always include the .md extension.

The [[path\|display text]] wikilink form maps to [display text](relative/path.md) in Markdown mode.

Scope: this setting affects only newly written or updated links. Existing vault content is never automatically migrated — users who want to convert old links can run the cross-linker or wiki-lint skill.

Every write skill reads OBSIDIAN_LINK_FORMAT from config before generating links and applies the correct format.

Config Resolution Protocol

All skills must resolve config using this algorithm — do not hard-code .env or ~/.obsidian-wiki/config directly. This ensures single-vault, multi-vault, project-local, and VPS setups all work correctly.

Resolution order

0. Inline vault override (@name) — if the user's request contains an @<name> token (e.g. @work save this, query @personal about X), resolve ~/.obsidian-wiki/config.<name> directly and use its OBSIDIAN_VAULT_PATH. This overrides both the CWD .env walk-up and the active symlink, and applies to that invocation only — never run ln -sf or otherwise change the active vault for an @name request. If ~/.obsidian-wiki/config.<name> doesn't exist, tell the user it doesn't exist and list the available vaults (the wiki-switch List logic), then stop — do not silently fall back to the default. The @name is a routing directive, not content: strip it out before treating the rest of the request as the actual instruction or page text.
1. Walk up from CWD — look for a .env file in the current directory, then each parent, up to $HOME. Stop at the first .env that contains OBSIDIAN_VAULT_PATH.
2. Global config — if no local .env found, read ~/.obsidian-wiki/config.
3. Prompt setup — if neither exists, tell the user: "No config found. Run wiki-setup to initialize your wiki."

@name is a per-invocation override — it targets one vault for one request. /wiki-switch <name> is the persistent default — it re-points the active symlink for all future requests. Use @name to touch the other vault from anywhere without disturbing your default ("brain") vault.

Vault-scoped state

Skills that write runtime state (e.g. daily-update) must scope that state to the resolved vault, not to a global path. Use:

Standard "Before You Start" block

Every skill's setup section should read:

Resolve config — follow the Config Resolution Protocol in llm-wiki/SKILL.md. Honor an inline @name override first, then walk up from CWD for .env, fall back to ~/.obsidian-wiki/config, else prompt setup. This gives OBSIDIAN_VAULT_PATH and any tool-specific path overrides.

Environment Variables

The wiki is configured through environment variables (see .env.example). The only required variable is the vault path — everything else has sensible defaults.

• OBSIDIAN_VAULT_PATH — Where the wiki lives (required)
• OBSIDIAN_SOURCES_DIR — Where raw source documents are
• OBSIDIAN_CATEGORIES — Comma-separated list of categories
• WIKI_SKIP_PROJECTS — Comma-separated substrings; any project dir whose name contains one is excluded from history ingest (scan + delta + manifest). See the "Project Scoping" step in the history-ingest skills.
• CLAUDE_HISTORY_PATH — Where to find Claude conversation data
• CODEX_HISTORY_PATH — Where to find Codex session data
• HERMES_HOME — Where to find Hermes agent data
• OPENCLAW_HOME — Where to find OpenClaw data
• COPILOT_HISTORY_PATH — Where to find Copilot session data
• OBSIDIAN_LINK_FORMAT — Internal link syntax: wikilink (default) or markdown
• WIKI_TOKEN_WARN_THRESHOLD — Emit a warning in wiki-status when the full-wiki token estimate exceeds this value (default: 100000). Set to 0 to disable. See wiki-status for the token footprint report.
• WIKI_STAGED_WRITES — When true, all LLM-written pages go to _staging/<category>/ for human review before promotion. See wiki-setup and wiki-stage-commit for details.

No API keys are needed — the agent running these skills already has LLM access built in.

Modes of Operation

The wiki supports three ingest modes:

Use wiki-status to see the delta and get a recommendation. Use wiki-rebuild for archive/rebuild/restore operations.

Reference

For details on specific operations, see the companion skills:

• wiki-status — Audit what's ingested, compute delta, recommend append vs rebuild
• wiki-rebuild — Archive current wiki, rebuild from scratch, or restore from archive
• wiki-ingest — Distill source documents into wiki pages and raw text/chat/log data
• claude-history-ingest — Ingest Claude conversation history
• codex-history-ingest — Ingest Codex CLI session history
• wiki-query — Answer questions against the wiki
• wiki-lint — Audit and maintain wiki health
• wiki-setup — Initialize a new vault*