# LLM Wiki Memory Upgrade Prompt

> One-click prompt to upgrade your AI agent memory system to Karpathy LLM Wiki pattern. Send to Claude Code / Cursor / Windsurf — auto audits, compiles fragments, resolves contradictions, builds structured wiki.

## Install

Paste the prompt below into your AI tool:

# LLM Wiki Memory Upgrade Prompt

> Based on [Karpathy's LLM Wiki pattern](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). Copy the prompt below and send it to your Claude Code / Cursor / Windsurf / any AI coding agent.

---

## 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:

```markdown
---
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:

| Operation | When | How |
|---|---|---|
| **Ingest** | After solving a hard problem or getting new feedback | Say: "Add this to my wiki: {lesson}" — AI updates the relevant `wiki-*.md` page |
| **Query** | Automatic | AI reads index + relevant pages at conversation start |
| **Lint** | Monthly or when things feel messy | Say: "Lint my memory" — AI audits for contradictions, stale info, duplicates |

## 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](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)
- Implementation: Adapted for Claude Code's persistent memory system by William Wang (TokRepo)


---
Source: https://tokrepo.com/en/workflows/f6d1f761-8d95-452b-9951-711a7cab05b0
Author: henuwangkai