LLM wiki pattern 2026-04-10

This source articulates the core pattern Shanepedia should embody: not RAG over raw documents at query time, but an incrementally compiled wiki maintained by the LLM over time.

Core thesis

The central idea is that knowledge should be compiled once into a durable markdown wiki and then continuously maintained. New sources should update existing pages, enrich synthesis, flag contradictions, and improve cross-links rather than forcing the model to rediscover everything from scratch on every query.

Key pattern elements

• raw sources remain immutable source-of-truth inputs
• the wiki is the maintained synthesis layer
• an agent instruction file governs ingest, query, and maintenance workflows
• useful analyses should be written back into the wiki instead of lost in chat history
• health checks should look for contradictions, stale claims, orphans, and missing concepts

Why it matters for Shanepedia

This source is unusually aligned with the repo's current direction. It effectively describes Shanepedia itself as a pattern: Obsidian as the browsing IDE, the LLM as the maintainer, markdown as durable memory, and source ingestion as a compounding process.

Why it matters for Codex specifically

This source maps cleanly onto a Codex workflow. Codex should be treated as the maintainer that updates the compiled markdown layer while Shane uses Obsidian to inspect, navigate, and pressure-test the results. The right comparison is not "better chat with files attached." It is "an agent maintaining a codebase whose language is markdown knowledge."

Practical implications

1. Shanepedia should optimize for wiki maintenance, not just query-time retrieval.
2. Important conversations and synthesized answers should become durable pages, dashboards, canvases, or briefs.
3. Raw source, wiki, and agent-schema layers should stay explicit.
4. Obsidian UX matters because it is the human interface to the compiled knowledge layer.
5. Local search and lint tools matter more as the wiki grows.

Best write-backs triggered by this source

• strengthen the repo's maintainer contract around ingest and health-check workflows
• make dashboards and maps first-class, because valuable queries should become persistent artifacts
• keep log and index maintenance central
• favor small local tools that help the agent maintain the wiki as scale grows
• encode the Codex + Obsidian loop explicitly so future agents do not treat Shanepedia like ordinary RAG