The foundational knowledge distillation pattern for building and maintaining an AI-powered Obsidian wiki. Based on Andrej Karpathy's LLM Wiki architecture. Use this skill whenever the user wants to understand the wiki pattern, set up a new knowledge base, or needs guidance on the three-layer archite

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 ): Category Purpose Example concepts/ Ideas, theories, mental models concepts/transformer architecture.md entities/ People, orgs, tools, projects entities/andrej karpathy.md skills/ How to knowledge, procedures skills/fine tuning llms.md references/ Summaries of specific sources; academic papers use the Paper Deep Dive Template (below) references/attention is all you need.md synthesis/ Cross cutting analysis across sources synthesis/scaling laws debate.md journal/ Timestamped observations, session logs journal/2024 03 15.md Projects Knowledge often belongs to a specific project. The projects/ directory mirrors this: 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: Special Files Every wiki has these files at its root: Write them with obsidian wiki memory , never by hand. index.md , log.md , hot.md , and the meta/ tables share one advisory lock and are written atomically; hand edits in a parallel run drop whichever write lands second. obsidian wiki memory sync <VERB key=value does all three in one call. The full procedure — verbs, the Key Takeaways slot that stays yours, the owner profile and todo index — is in [ references/MEMORY.md ](references/MEMORY.md). 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 Source key contract (v2). Source keys — the sources keys in .manifest.json , the sources: frontmatter values on pages, and a project's source repo — MUST be machine portable. A vault is synced across machines, so a bare absolute path ( /Users/... , /home/... ) is never a valid stored key. This is the single canonical definition; other skills reference it rather than restating it. Where the source lives Canonical key form Example Inside the vault vault relative path — POSIX separators, no leading ./ , no .. Raw/database/postgres.pdf , Clippings/article.md Under $HOME home relative path — starts with ~ ~/.claude/projects/ Users name my app/abc.jsonl Not a file at all pseudo key — any scheme: / :// identifier, treated as opaque url:https://example.com/article , agent:claude/<session id Rules: 1. Never store a bare absolute path. Convert before writing, not after. 2. Normalize before comparing. Expand ~ and environment variables, resolve vault relative keys against the vault root, and treat scheme: / :// pseudo keys as opaque identifiers. Never compare raw strings without normalizing first. 3. Identity survives path changes. The same logical source keeps the same key across machines. 4. Pseudo keys are an open namespace. What makes a key a pseudo key is its shape ( scheme: or :// , so it can never be mistaken for a file path), not a fixed list of names. Recommended names: repo:<host/owner/name for a git project, url:<canonical url for a web page, agent:<agent /<id for an agent session. A source that is neither in the vault nor under $HOME still needs one — do not let it fall back to an absolute path. 5. Project identity is a repository, not a checkout. In the projects block, identify a project by source repo ( host/owner/name ) rather than a machine path. A machine specific checkout location, if useful at all, belongs in an optional source cwd hint ( ~ relative), never in the identity. Reading is backward compatible: an existing manifest full of absolute keys keeps working, and scripts/manifest.py migrate <vault dry run converts it to contract v2 (merging collisions, keeping the newest ingested at ). If the vault has moved between machines , its absolute keys are rooted at the old vault path, which matches neither the new vault nor $HOME — pass that old root explicitly with migrate <vault from root <old vault root (repeat the flag if the vault lived at more than one location). The command then reports nothing portable to write — N key(s) kept non portable rather than claiming success. New writes go through the same normalization, so a skill may pass an absolute path to obsidian wiki cache update and still have a portable key land in the manifest. 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: Sources section (required, last body section). Every wiki page ends with Sources . Entries must be clickable in Obsidian: Local snapshot (raw ingest, dropped PDFs/images, Web Clipper files, anything that landed in raw/ and was archived): [[ raw/ archived/<filename ]] in the body Sources section (body wikilinks may include .md ). YAML sources: stays origin keys ( url: , agent: , repo paths, …), not the archive path. YAML snapshots: is separate: after moving a file to raw/ archived/ , run obsidian wiki snapshots set <page archive raw/ archived/<filename then obsidian wiki cache update on that archived path. The CLI writes a List of quoted wikilinks with display text, e.g. "[[ raw/ archived/clip clip]]" (no .md in the target; clip is what Properties shows). Do not put Markdown [title](path) in snapshots: — Properties leaves those as unclickable text. The snapshots CLI does not touch the body. Do not link the webpage recorded in clipping frontmatter — that URL is mutable origin metadata. Fetched URL ( /ingest url with no saved snapshot): a markdown link to the canonical URL, and YAML sources: as url:<canonical url . Do not mix those up. A clip of a page is not an ingest from URL. Related wiki pages stay in Related / relationships: , not in Sources. Parser safe scalars. Write free text frontmatter values — at minimum title and summary — with folded scalar syntax ( ) as shown above: a bare scalar containing : (colon + space), , or quotes breaks YAML parsing, and Obsidian then reports "Invalid properties" and hides the frontmatter. Keep the value indented on the line(s) following title: / summary: . 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. These are framework defaults. A vault's AGENTS.md may add markers or workflow flags. Preserve owner extensions and treat orthogonal workflow flags separately from the extracted/inferred/ambiguous truth state axis. State Marker Meaning Extracted (no marker — default) A paraphrase of something a source actually says. Inferred

llm-wiki