# LLM Wiki Patterns

## Core Model

An LLM Wiki is not ordinary RAG. The agent compiles source material into a persistent, cross-linked Markdown wiki that grows through every ingest, query, compile, lint, teach, and audit operation.

Use three conceptual layers:

- Source layer: read-only source material such as articles, papers, clips, notes, books, transcripts, images, and pointer files for large assets.
- Wiki layer: LLM-maintained Markdown pages that summarize, synthesize, teach, and cross-link knowledge.
- Schema layer: project instructions such as `CLAUDE.md`, `AGENTS.md`, a vault convention note, or a map-of-content page that describes scope, naming, page types, source policy, and workflows.

## Flexible Layouts

Respect the user's existing layout. Common structures:

```text
<wiki-root>/
  raw/
  wiki/
    index.md
    log.md
  audit/
    resolved/
```

```text
<wiki-root>/
  sources/
  notes/
  maps/
  reviews/
```

```text
<wiki-root>/
  CLAUDE.md
  log/YYYYMMDD.md
  wiki/concepts/
  wiki/entities/
  wiki/summaries/
  outputs/queries/
  audit/resolved/
```

Do not migrate the vault just to match a template. Create missing pieces only when they help the user's workflow.

## Page Types

### Topic Page

Purpose: overview, scope, learning path, map of modules, important concepts, and source coverage. Topic pages should guide navigation rather than carry all detail.

Suggested sections:

- What this topic helps you understand
- Learning path
- Module map
- Key concepts
- Common confusions
- Open questions
- Source coverage

### Module Page

Purpose: detailed, reviewable explanation of a coherent subtopic.

Suggested sections:

- Module claim
- Mechanism or process
- Examples
- Counterexamples
- Mistakes and traps
- Practice questions
- Sources

### Concept Page

Purpose: reusable idea that appears across multiple topics.

Suggested sections:

- Definition
- Plain-language explanation
- Boundaries
- Related concepts
- Applications
- What would change this
- Sources

### Entity Page

Purpose: people, tools, organizations, products, papers, datasets, places, or projects.

Suggested sections:

- What it is
- Why it matters
- Relevant claims
- Related topics
- Sources

### Source Page

Purpose: structured extraction from a source that has independent value or needs provenance.

Create source pages when citation, provenance, or source-level review matters. Do not create one source page per note by default if the material is better compiled into topics and modules.

### Learning Section

Add learning sections to topic, module, or concept pages when the goal includes understanding, judgment, or reading practice:

- Socratic questions
- Feynman explanation prompt
- Debate prompt
- Judgment drill
- Real-world application
- Follow-up reading path

## Note Rebuilding

Use this when reorganizing messy notes, exported notebooks, book notes, course notes, or research folders.

1. Sample the source collection and infer its natural domains.
2. Identify stable topics, modules, concepts, and entities.
3. Preserve useful original hierarchy only when it helps review.
4. Merge fragments that belong to the same module.
5. Split pages that mix navigation and detail.
6. Convert raw highlights into explanations, examples, questions, and source-backed claims.
7. Add backlinks and navigation pages so the result is browsable in Obsidian.

Avoid mechanical cleanup. The rebuilt wiki should help the user review, reason, compare, and apply the material.

## Learning Methods

### Hunting Method

Use when the user is reading with curiosity, emotion, or a live purpose.

- Start with a real question or tension.
- Search or scan multiple sources if available.
- Stop on high-signal passages.
- Extract the "catch": insight, claim, model, objection, or example.
- File it into the most relevant page.
- Do not force completion of a book or source when the purpose has been served.

### Feynman Method

Use when the user needs deep understanding.

- Ask the user to explain the idea plainly.
- Probe definitions, mechanisms, assumptions, and examples.
- Ask for a child-level explanation.
- Identify gaps and send them back to source pages.
- Save durable clarifications and practice questions in the wiki.

### Debate Method

Use when the user wants judgment, taste, non-consensus thinking, or multi-model reasoning.

- Select a claim from the source or wiki.
- Generate contrasting perspectives from different disciplines.
- Surface incentives, edge cases, failure modes, tradeoffs, and second-order effects.
- End with a judgment drill: what evidence would change the conclusion, and what decision would the user make now?

## Naming

- Follow the vault's existing naming style.
- Keep filename language and page-title language aligned unless the vault already has a mixed convention.
- Use stable, descriptive slugs for pages that will be heavily linked.
- Avoid renaming many files without a link migration plan.

## Index Or Map

The index or map-of-content is a navigation tool, not a long summary.

```markdown
# Index

## Topics
- [[topic-example]] - one-line scope

## Modules
- [[module-example]] - one-line role

## Concepts
- [[concept-example]] - reusable idea

## Entities
- [[entity-example]] - relevant person/tool/project

## Sources
- [[source-example]] - source summary

## Learning Paths
- [[topic-example#Learning path]]

## Open Questions
- ...
```

Every durable wiki page should be reachable from the index, map, or a nearby topic page.

## Log

Use the vault's existing history convention. A simple format:

```markdown
## [2026-04-25 14:30] ingest | source-name

- Updated: [[module-example]], [[concept-example]]
- Added: [[source-example]]
- Noted: conflict with [[concept-old]]
```

Common operations: `init`, `ingest`, `query`, `promote`, `teach`, `compile`, `split`, `merge`, `lint`, `audit`.


