LLM Wiki Memory Upgrade Prompt

Usage

Copy everything between the ---START--- and ---END--- markers below, paste it into your AI agent's chat.

---START---

Task: Upgrade my memory system to Karpathy's LLM Wiki pattern

I want you to upgrade my persistent memory/knowledge system into a structured, self-maintaining wiki based on Karpathy's LLM Wiki architecture (3-layer: Raw Sources → Compiled Wiki → Schema, with Ingest/Query/Lint operations).

Step 1: Audit (read-only, report to me)

Read my current memory index file and list all memory files. Then analyze and report:

1. Inventory: How many files? Total size? File types breakdown?
2. Contradictions: Rules that conflict with each other (e.g., "do X" in one file vs "don't do X" in another). Often caused by preferences evolving over time where old rules weren't cleaned up.
3. Duplicates: Files that say essentially the same thing (merge candidates).
4. Stale content: Progress trackers for finished projects, rules referencing discontinued tools/platforms, dates that have passed.
5. Fragmentation score: How many files have <20 lines and could be compiled into domain pages?
6. Missing structure: Is there a schema? Are files categorized? Is the index clean?

Present the audit as a table and wait for my approval before proceeding.

Step 2: Create SCHEMA.md

Create a SCHEMA.md file that documents how this wiki works:

---
name: Wiki Schema
description: How this memory wiki operates — Ingest/Query/Lint, file naming, maintenance rules
type: reference
---

# Memory Wiki Schema (Karpathy LLM Wiki Pattern)

## Three Layers

1. **Raw Sources** — Code, chat history, web pages (ephemeral, not persisted)
2. **Wiki Pages** — Compiled, structured knowledge (the .md files in this directory)
3. **Schema** — This file, defining how the wiki operates

## Three Core Operations

### Ingest
- Trigger: Solved a non-trivial problem, learned something new, user gave new feedback
- Rule: Check if an existing wiki page can be updated BEFORE creating a new file
- Related feedback gets COMPILED into domain pages, not stored as individual fragments

### Query
- Memory index auto-loads at conversation start
- Read specific wiki pages on-demand for detailed knowledge
- Compiled pages are more efficient than reading 20+ fragment files

### Lint (Health Check)
- Frequency: Monthly, or when user says "lint memory" / "clean up memory"
- Checks: ① Contradictions ② Stale info ③ Duplicates ④ Orphan pages (not in index)
- Each wiki page tracks `last_lint: YYYY-MM-DD`

## File Naming Convention

| Prefix | Purpose | Example |
|---|---|---|
| `wiki-` | Compiled domain knowledge (multiple feedbacks merged) | `wiki-coding-style.md` |
| `*-skill.md` | Operational playbook (workflow SOP) | `deployment-skill.md` |
| `*-progress.md` | Ongoing project progress tracking | `migration-progress.md` |
| `*-context.md` | Project context (arch, config, deploy) | `backend-context.md` |

## Maintenance Rules

1. **One domain, one page** — Don't create separate files for each feedback, compile into domain pages
2. **Index stays under 100 lines** — Only pointers, no content
3. **Wiki pages track last_lint date** — For freshness tracking
4. **Deleting > Creating** — On every Ingest, check if old content can be replaced

Adapt the naming conventions to match my existing files.

Step 3: Compile fragments into wiki pages

Group related small files (especially feedback/rules) into compiled domain wiki pages:

• Identify domains: Look at the topics of my feedback files. Common domains: coding style, communication preferences, tool-specific rules, project-specific rules, workflow preferences.
• Create wiki-{domain}.md pages: Each page compiles ALL rules for that domain, with:
  • Frontmatter (name, description, type)
  • Clear sections with the compiled rules
  • last_lint: {today's date} at the top
  • Links to detailed playbooks/skills if they exist
  • A "History" section noting how rules evolved (helps future Lint detect stale rules)
• Preserve all knowledge: Every rule from every fragment must appear in a compiled page. Don't lose any information.
• Resolve contradictions: When two rules conflict, keep the NEWER one and note the old one in the History section.

Step 4: Rewrite the memory index

Rewrite the main index file as a clean, categorized wiki index:

• Under 100 lines
• Categorized (not a flat list): Identity, Behavior Rules, Projects, Skills, etc.
• One-line entries: - [Title](file.md) — short description
• Header: Include a link to SCHEMA.md and today's date as last_lint

Step 5: Delete superseded files

After compiling, delete the original fragment files that have been fully absorbed into wiki pages. List what you're deleting and why before doing it.

Step 6: Report

Show me:

• Before vs After comparison (file count, index line count, contradictions fixed, duplicates removed)
• The new file structure
• Any large files (>10KB) that might benefit from future splitting or archiving

Important Constraints

• Don't lose any knowledge — Every rule must survive in a compiled page
• Don't touch skill/playbook files — Those are operational SOPs, not fragments to merge
• Don't touch progress tracking files — Those are living documents
• Preserve credentials and config — Don't remove connection strings, API keys, deploy commands
• Ask before deleting if unsure whether something is still active

---END---

What happens after the upgrade

Once your memory is upgraded to the wiki pattern, maintain it with these habits:

Optional: Auto-Lint Hook

If your agent supports hooks/scheduled tasks, you can set up an auto-lint:

Every 30 days, run a Lint on my memory wiki:
1. Read SCHEMA.md and MEMORY.md
2. Check each wiki page for contradictions, staleness, orphans
3. Report findings but don't auto-fix without my approval

Credits

• Pattern: Andrej Karpathy's LLM Wiki
• Implementation: Adapted for Claude Code's persistent memory system by William Wang (TokRepo)