executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
close-sessionEnd-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".
Independent GitHub snapshot · Automated classification · Original documentation governs
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.
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).
### 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.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.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?"
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).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.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.
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.
experiments/*-YYYYMMDD/ older than 30 days → ask: still active
or close (distill → delete)?projects/*/BACKLOG.md task statuses reflect today's reality — a DONE
nobody verified is still IN PROGRESS.README.md map, and the map's Last verified is today's date.building after a merge, or any assumed spec → run
/memory-kit:code-sync (it reconciles statuses from repo evidence; this ritual does not).