# LLM Wiki

A personal knowledge base maintained by Claude Code.
Based on Andrej Karpathy's LLM Wiki pattern.

## Purpose

This wiki is a structured, interlinked knowledge base for <ADD YOUR PURPOSE HERE>.
Claude maintains the wiki. The human curates sources, asks questions, and guides the analysis.

## Folder structure

```
raw/          -- source documents (immutable -- never modify these)
wiki/         -- markdown pages maintained by Claude
wiki/index.md -- master table of contents with one-line descriptions
wiki/log.md   -- append-only record of all operations (newest entry first)
templates/    -- a directory of templates to be used when creating pages (optional)
```

## Page format

Every wiki page must follow this structure exactly:

```markdown
# Page Title

**Summary**: One to two sentences describing this page.

**Sources**: `filename1.pdf`, `filename2.md`

**Last updated**: YYYY-MM-DD

---

Main content here. Use clear headings and short paragraphs.
Link to related concepts using [[wiki-links]] throughout.

## Related pages

- [[related-concept-1]] — one-line description of relationship
- [[related-concept-2]] — one-line description of relationship
```

Page naming: lowercase with hyphens (e.g. `transformer-architecture.md`).

## Log format

Each `wiki/log.md` entry must follow this exact format:

```
## YYYY-MM-DD — <operation type>

**Source**: filename (for ingests) or "n/a"
**Pages created**: page-a.md, page-b.md
**Pages updated**: page-c.md
**Summary**: One sentence describing what changed and why.
```

Entries are prepended (newest first). Never edit or delete existing entries.

## Ingest workflow

When the user adds a new source to `raw/` and asks you to ingest it:

1. Read the full source document
2. Read `wiki/index.md` to understand existing coverage
3. Identify which existing pages will be affected, and flag any overlap or contradiction with what's already in the wiki
4. Discuss key takeaways and your proposed page plan with the user before writing anything
5. Create a summary page in `wiki/` named after the source
6. Create new concept pages for major ideas not yet covered; update existing pages rather than duplicating coverage
7. Add [[wiki-links]] to connect related pages in both directions
8. Update `wiki/index.md` with all new pages and their one-line descriptions
9. Prepend an entry to `wiki/log.md` following the log format above

A single source may touch 10–15 wiki pages. That is normal. When unsure whether a concept warrants its own page vs. a section on an existing page, ask the user.

## Citation rules

- Every factual claim must reference its source using `(source: filename.pdf)`
- If two sources disagree, note the contradiction explicitly and do not silently resolve it
- If a claim has no source, mark it `[needs source]`
- If a source is superseded by a newer one, note this on both pages

## Question answering

When the user asks a question:

1. Read `wiki/index.md` to identify relevant pages
2. Read those pages and synthesize a direct answer
3. Cite specific wiki pages in your response
4. If the answer is not in the wiki, say so clearly and identify which pages are closest
5. If answering the question surfaces new knowledge worth keeping, offer to save it as a new wiki page

Good answers compound over time — file them back into the wiki.

## Lint

When the user asks you to lint or audit the wiki:

- Check for contradictions between pages
- Find orphan pages (pages with no inbound [[wiki-links]] from other pages)
- Find broken links ([[wiki-links]] pointing to pages that don't exist)
- Identify concepts mentioned in text that lack their own page
- Flag claims marked `[needs source]`
- Flag claims that may be outdated based on newer source dates
- Check that all pages follow the page format above
- Report findings as a numbered list with suggested fixes, ordered by severity

## Rules

- Never modify anything in `raw/`
- Always update `wiki/index.md` and `wiki/log.md` after any change
- Check existing wiki coverage before creating new pages — prefer updating over duplicating
- When uncertain about scope, categorization, or conflicts, ask the user before writing
- Write in clear, plain language — prefer short sentences over dense prose