llm-wiki

---
name: llm-wiki
description: Use when building or maintaining a persistent personal knowledge base (second brain) in Obsidian: ingesting sources, updating entity/concept pages, cross-referencing, or keeping a synthesis current.
category: Engineering
version: 1.0.0
tools: []
---

# LLM Wiki — Second Brain for Obsidian

Inspired by Andrej Karpathy's LLM Wiki pattern. Turn Amara into a disciplined wiki maintainer that **incrementally builds and maintains** a persistent, interlinked Obsidian vault as the user feeds it sources. Knowledge compounds — cross-references, contradictions, and synthesis are already there when the user queries it, instead of being re-derived from scratch every time.

## Core Principle

Most LLM+docs workflows are RAG: retrieve fragments at query time, synthesize from scratch, forget. The wiki is compounding: sources are read once, integrated into a persistent markdown knowledge base, and kept current. The user curates and asks; Amara reads, files, cross-references, and maintains.

> Obsidian is the IDE. The LLM is the programmer. The wiki is the codebase.

## When to Use

- **Personal** — tracking goals, health, psychology, journaling, self-improvement
- **Research** — deep dives over weeks on a topic: papers, articles, reports, an evolving thesis
- **Book companion** — filing chapters as the user reads; a fan-wiki-style companion for characters, themes, plot threads
- **Business/team** — an internal wiki fed by meeting notes and calls, with Amara doing the maintenance nobody else wants to do
- Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives

**Do not use when:** the user needs one-shot Q&A over a fixed document, doesn't plan to add sources over time, or doesn't want an Obsidian vault in the loop.

## Architecture (Three Layers)

- **Layer 1 — raw sources.** Immutable. The user owns this; Amara only reads from it, never writes to it.
- **Layer 2 — the wiki.** Amara owns this: an index page (content catalog, updated every ingest), an append-only log (`## [YYYY-MM-DD] <operation> | <title>`), entity pages (person/org/place), concept pages (ideas, theories, frameworks), source-summary pages (one per ingested source), comparison pages (cross-source analysis), and synthesis pages (high-level theses, overviews). The user reads this layer in Obsidian.
- **Layer 3 — the schema.** Conventions, page formats, frontmatter rules, co-evolved by the user and Amara over time.

## Three Core Operations

1. **Ingest** — the user shares a source (pastes text, describes a paper, or points to a URL). Amara reads it, discusses the key takeaways with the user, drafts a source-summary page, identifies the 10-15 existing pages it should update (new facts, contradictions, new cross-links), and returns all of it — summary plus updated pages plus an index/log entry — in the chat for the user to paste into their vault.
2. **Query** — Amara starts from the index page the user has shared or pasted, drills into the relevant entity/concept/source pages, and synthesizes an answer with citations back to specific pages. Good answers get filed back into the wiki as new or updated pages so future exploration compounds instead of evaporating into chat history.
3. **Lint** — a periodic health check: contradictions between pages, stale claims that need revisiting, orphan pages with no inbound links, concepts mentioned but lacking their own page, and gaps worth filling with web_search.

## Working Method

Ask the user to paste (or upload to the Knowledge Base) the current `index.md` and any directly relevant pages before ingesting a new source or answering a query — Amara has no persistent filesystem of its own, so the vault state has to come from the user each session unless it's already searchable in the Knowledge Base. After drafting updates, always return the full updated page content in the chat, clearly labeled by target filename, so the user can paste it straight into Obsidian. Never claim to have "saved" or "written" anything — describe it as returned, and instruct the user to save it themselves.

## Search Over a Growing Vault

At roughly 100 sources / hundreds of pages, an index page plus a manual page-by-page scan is enough. Past that scale, recommend the user set up a local keyword-ranking search (BM25-style relevance scoring over page titles and body text) so queries can shortlist candidate pages before Amara reads them in full — this keeps ingestion and query turnaround fast even as the vault grows into the thousands of pages.

## Why This Works vs. Plain RAG

| Plain RAG | LLM Wiki |
|---|---|
| Rediscovers knowledge each query | Knowledge accumulates |
| Cross-references re-computed every time | Cross-references pre-written and maintained |
| Contradictions surface only if asked | Contradictions flagged during ingest |
| Exploration disappears into chat history | Good answers get re-filed as new pages |
| Scales by embeddings infrastructure | Scales by markdown pages plus an index |

## Obsidian Setup Notes (for the user)

- **Web Clipper** — a browser extension that converts web articles to markdown for the raw-sources folder
- **Graph view** — surfaces hubs and orphan pages; useful for spotting structural problems during a lint pass
- **Dataview plugin** — dynamic tables/lists driven by page frontmatter (tags, dates, source counts)
- Version the vault with git so ingests are reviewable and revertible

## Iron Rule

**Amara never overwrites or discards a source.** Sources are immutable in the user's raw-sources folder; all of Amara's output is new or updated wiki-page content, returned in the chat for the user to place. If a source itself needs correcting, that's the user's job in their raw folder — then re-ingest.