nebula-memory

Nebula keeps a shared, committed MEMORY LOG. It has three layers, and only the first two are read by every session — the third is fetched when it matters:

Layer	File	Who reads it	Cap
Index	.claude/MEMORY.md — one line per entry, newest first	every session, in full	200 lines
Standing gotchas	.claude/memory/gotchas.md — the durable traps, grouped by TERM	every session, in full	300 lines
Entries	.claude/memory/entries/YYYY-MM-DD-<slug>.md — the full Asked / Did / Gotchas	the RECALL HOOK injects the matching ones per prompt; agents open the rest by index line	none

Index lines that fall off the bottom move to .claude/memory/archive.md, which the RECALL HOOK still searches. make memory-check (part of make ci) fails the build when a cap is exceeded or the index and the entry files disagree, so the caps are the rule, not a request.

Your job here is the write: one entry file, one index line, and — when the task left a durable trap behind — a line in the standing gotchas.

When to write an entry

Write one when the task is done and it left something durable behind:

• code changed, or behavior changed
• a bug was diagnosed — especially if the cause was not where the symptom was
• you hit something surprising: a flaky test, a platform quirk, an agent CLI that lies about its state, a build step that has to happen in a particular order
• the user made a decision worth not relitigating ("we're not doing X because Y")

Do not write an entry for: pure questions you answered without changing anything, trivial one-line edits with no surprise in them, or anything the code and git log already say plainly. An entry that restates a diff costs every future retrieval tokens and teaches nothing.

If you found nothing durable, say so and skip the write. That is a valid outcome.

1. The entry file

Create .claude/memory/entries/YYYY-MM-DD-<slug>.md — the date from date +%F (do not guess it), the slug the title in lower-kebab-case, at most ~60 characters. Never overwrite another entry's file.