close-session git:20261022.af5bf98A

Immutable. This exact content never changes and is served at /api/v1/blob/7a187dce8977e268.

---
name: close-session
description: End-of-session ritual — audit today's patterns against accumulated memory, propose promotions, refresh MEMORY.md, and write the session handoff. Use when the user says "/memory-kit:close-session", "закрой сессию", "закрываем", "we're done for today", "wrap up".
allowed-tools: Read, Write, Edit, Grep, Glob
---

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

You close the session in four steps. Don't just dump — **audit**. Everything you write, you
announce briefly; anything promoted to rules/concepts needs the user's verbal "yes" first.

## Step 1 — Capture what's new
Scan this session for observations worth keeping. Append each to `.claude/memory/MEMORY.md`
as a ONE-LINE `[YYYY-MM-DD]`-prefixed entry. Short, scannable, no essays (long rationale
belongs in a concept article, step 2).
- **File each line under a TOPIC heading** of the patterns section (engineering, process,
  infra, the domain…) — create the topic if none fits. Never open a heading named after the
  session or the date (`### s66 (2026-09-25)`, `## Session 65 wrap`): the date lives in each
  line's prefix, the session narrative lives in the handoff (step 4). The SessionStart hook
  flags such headings.
- **Don't capture what the always-loaded layer already says** (`CLAUDE.md`, rules without
  `paths:`) or a number whose source of truth lives elsewhere (a price table, a config) —
  point at the source instead of copying the value.

## Step 2 — Audit & promote (the valuable part)
Read the date-tagged entries in MEMORY.md. Look for repetition: **did this pattern appear on
3+ different dates?** Surface 2-4 candidates, be specific: "noticed [date], [date], [date] you
said X — codify as a rule or a concept article?"
- 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
The header (everything above the first `---`) is «current state of work», 2-3 sentences,
**REPLACED** every close — never a chronicle of past sessions. Per-session detail lives in the
handoff, not stacked in the header.

## Step 4 — Write the handoff
Copy `context/handoffs/HANDOFF-TEMPLATE.md` → `context/handoffs/<topic>-<YYYY-MM-DD>.md` and
fill its five sections (what was done · where things stand · memory updates · next steps ·
opening note). The SessionStart hook injects the newest handoff next time — this file IS the
"remember where we left off" mechanism.

## 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.
- **Specs vs code:** any spec still `building` after a merge, or any `assumed` spec → run
  `/memory-kit:code-sync` (it reconciles statuses from repo evidence; this ritual does not).
- **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 group today's lines under a session heading — see Step 1.
- Don't write a handoff longer than ~1 screen (about 4,000 characters). It's a note, not a transcript.
  Session start injects 6,000 characters of it; the opening-note section always arrives whole, the rest
  is cut — so the next session's first move belongs in that section, not in step 4's list.