/close-session — the end-of-session ritual

Step 1 — Capture what's new

.claude/memory/MEMORY.md

[YYYY-MM-DD]

Step 2 — Audit & promote (the valuable part)

• User says yes → write

  knowledge/concepts/<topic>.md

  (facts + rationale; frontmatter per

  knowledge/index.md

  spec) or

  .claude/rules/<name>.md

  (mechanical always/never constraint; only for patterns stable 6+ months). Update

  knowledge/index.md

  (one line per concept).
• Promoted or long-absorbed entries get PRUNED from MEMORY.md — that's how it stays under its caps (180 lines / 32 KB / 3000 chars per line).
• Writing a fact into a second place?

  reference/doc-governance.md

  — one SSOT per fact, and when a fact changes you grep its restatements in the same pass. A product or architecture decision goes to the ledger instead —

  projects/<name>/decisions-log.md

  , format in

  reference/decisions-log.md

  . A plan, a spec, a research finding or a QA record is NOT memory: it belongs in that project's folder, per the map in its

  README.md

  .

Step 3 — Refresh the MEMORY.md header

---

Step 4 — Write the handoff

context/handoffs/HANDOFF-TEMPLATE.md

context/handoffs/<topic>-<YYYY-MM-DD>.md

Also check (30 seconds)

• Experiment hygiene: any

  experiments/*-YYYYMMDD/

  older than 30 days → ask: still active or close (distill → delete)?
• Backlogs:

  projects/*/BACKLOG.md

  task statuses reflect today's reality — a

  DONE

  nobody verified is still

  IN PROGRESS

  .
• Project map: anything you wrote today into a project folder is a row in that project's

  README.md

  map, and the map's

  Last verified

  is today's date.
• Caps: if MEMORY.md is near any cap, do a deeper prune now, not "next time".

What NOT to do

• Don't promote without the user's yes. Repetition makes a CANDIDATE, not a rule.
• Don't stack "Prior session" paragraphs in the MEMORY header — replace it.
• Don't write a handoff longer than ~1 screen. It's a note, not a transcript.