closelisted

# /close — session close Closing well means that three weeks from now the user (or you) knows what was done, why, and what was left dangling. This is not a pretty summary: it is **persisting what would otherwise be lost** and **telling the truth about what was left half-finished**. ## Step 1 — Real repo state Before summarising anything, look at the facts: ```bash git status --short git diff --stat git log --oneline -8 git stash list ``` Uncommitted work is first-class closing information. Do not commit it — commit only when the user asks — but **report it explicitly**. ## Step 2 — Review the conversation Walk the whole session and sort it into four buckets: 1. **Done** — what works now that did not work before. Concrete and verifiable. 2. **Decided** — what the user chose and **why**. The why is what gets lost. 3. **Ruled out** — what was tried and failed, and the reason. This stops the next session walking back into the same dead end. 4. **Open** — what is half-done, blocked, or unverified. Be honest in bucket 4. If something was left untested, say so. If a test fails, say so with its output. ## Step 3 — Distil into memory Follow `memory-triage.md` (same skill folder). Read it before writing anything. The filter in one line: only what the next session **cannot deduce** by reading the repo gets in. Look for duplicates before creating files. Update the `MEMORY.md` index. If nothing passes the filter, say so and move on. That is a valid result. ## Step 4 — Lig