| name | compile-knowledge |
| description | Compile durable knowledge into interlinked-markdown stores the "karpathy method" way — atomic files, [[wiki-links]], a maintained index. Use after producing research, intel, a digest, a learned non-obvious fact, or finishing any knowledge-shaped task, BEFORE you close it. Also when asked to "save this", "write this to the wiki", "update the wiki/memory", "log this finding", "structure this knowledge", or "follow the karpathy method". |
compile-knowledge
Durable knowledge is worth keeping as many small, interlinked markdown files,
compiled over time and surfaced through an index — not as one giant doc, a chat
log, or a one-off file that rots. This skill makes compiling consistent so your
agent gets smarter over time instead of relearning the same things.
Where it goes — pick the right store
- Agent memory (default, always available): your
.claude/.../memory/
folder with MEMORY.md as the index. This is the per-agent store and it
survives restarts — it's the karpathy "external memory" that keeps you sharp
across sessions. Governed by the memory rules already in your system prompt —
follow them. For most agents this is the only store you need.
- Shared wiki (only if you work as a team): a
wiki/ folder in your project
with a wiki/index.md. For knowledge the whole team benefits from — domain
facts, research findings, reference material multiple agents would re-derive.
Skip this entirely if you're a solo agent; don't manufacture team ceremony.
Rule of thumb: "only I act on this" → memory. "Anyone on my team might need
this" → shared wiki. Cross-link between them with [[slug]] when they relate.
Before you write — the hygiene gate
Compile ONLY a durable, non-obvious fact. Skip and move on if it is:
- routine / derivable from the repo, git history, or existing docs,
- true only for this one conversation,
- already covered by an existing file (→ UPDATE that file instead, don't duplicate).
Most tasks (a deploy, a restart, a one-line fix) produce nothing durable. That is
fine — do not manufacture a memory to "have written something." Filler is worse
than nothing; it pollutes recall.
The procedure
- Search first. Look for an existing file on this topic (grep the store +
skim the index). If one exists, edit it — never create a near-duplicate.
- Atomic. One fact / one topic per file. If you're tempted to add a second
unrelated fact, that's a second file.
- Name it. kebab-case slug, with a type prefix for memory
(
feedback_…, project_…, reference_…, user_…) or a clear topic slug for
the wiki. The slug is the link target.
- Frontmatter.
name (= the slug), description (ONE line — this is what
gets matched during recall, make it specific), and a type/category.
- Body. State the fact plainly. Link related entries with
[[slug]] —
liberally; a link to a file that doesn't exist yet is a fine TODO marker. For
feedback/project, follow with Why: and How to apply: lines.
- Index. Add or update a ONE-LINE pointer in the index (
MEMORY.md for
memory; wiki/index.md for the wiki): - [Title](slug.md) — hook. Keep it
under ~200 chars; detail lives in the file, never the index. If the wiki
index.md doesn't exist yet, create it so the store stays discoverable.
- Hygiene. Delete files that turned out wrong. Convert relative dates to
absolute. If the index is getting long, tighten lines — don't let it bloat.
Lifecycle — supersede, don't silently overwrite
Facts rot. When one is time-sensitive, uncertain, or replaces an older one,
stamp the envelope so recall can age it out instead of surfacing stale truth:
valid_to: YYYY-MM-DD — date the fact expires / needs a recheck. Past it,
recall keeps the fact but demotes + flags it ⚠ expired.supersedes: <slug> — when a new fact replaces an old one, point at the
old slug. The old fact is then demoted (⤴ superseded) in recall instead of
lingering as a second, contradictory answer. Prefer this over edit-in-place
when the OLD value is still worth seeing (audit trail); edit in place when it
isn't.confidence: high|medium|low — low/medium facts are demoted so a hunch
never outranks a verified fact.provenance: "<source>" — where the fact came from, distinct from
compiled_by (who wrote the note).
5dive memory add writes these: --valid-to=, --supersedes=, --confidence=,
--provenance=. All optional — omit them and behaviour is unchanged.
Anti-patterns
- A wall-of-text doc instead of atomic files.
- Research left as a standalone
notes.md that never gets folded in — that's
working notes, not knowledge. Compile the durable parts into the store.
- Duplicating a fact across memory AND wiki — pick one home, cross-link.
- Index entries that restate the whole file.
- Writing filler to satisfy a habit/checklist.
Quick checklist
[ ] durable & non-obvious? [ ] right store? [ ] updated existing vs new?
[ ] atomic + named + frontmatter? [ ] [[links]]? [ ] index line added?
