/close-chat — Session closeout

Run a structured closeout pass at the end of a Claude Code session so the persistent record (memory, deliverables, LORE, TODOS, git, tasks) reflects what just shipped, what's parked, and what's still open. Output is a short status report the user can scan before the chat is archived.

When to use

• Explicit invocation: /close-chat
• User says (in order of strength): "close chat", "let's close out", "prepare to close", "wrap up", "session wrap", "end of session", "before I close"
• After shipping a substantive artifact (PR opened, deploy landed, major doc finalized) — even without an explicit phrase, surface the closeout prompt
• Do NOT auto-run for trivial sessions (single-question chats, doc-only commits, conversational exchanges)

The nine-item checklist

Walk through each item in order. For each: act if applicable, or explicitly say "skipped — not relevant this session." Silence on a step is not a pass.

1. Project memory

If the session touched a tracked project (anything in MEMORY.md index), update the relevant project_*.md:

• Current shipped state (PR links, commit SHAs, version)
• Real data points if surfaced (e.g., concrete progress numbers like "3/3/7 complete" instead of stale "8 weeks")
• Parked work (local branches, deferred follow-ups)
• Key files index for fast orientation
• Update or rename the file if the project's identity shifted (route renames, scope changes); also update MEMORY.md index entry

If the session started a new project, write a fresh project_*.md and add a line to MEMORY.md.

2. Deliverables log

If the session shipped a prototype or ReOps deliverable, write ~/dev/deliverables/YYYY-MM_<slug>.md using ~/dev/deliverables/TEMPLATE.md. The "core five":

1. Problem — one sentence
2. Solution — what was built, how it works mechanically, the stack
3. AI proficiency demonstrated — specifically how Claude was used (be concrete: skill invocations, math-checks, iteration patterns, review handling)
4. Value delivered — who benefits, what changed, quantifiable where possible
5. Links — code paths, PR URLs, source data, related docs

Plus optional: Risks mitigated, Future-proofing, Stakeholders.

Skip if no shipped artifact (e.g., research/discussion session, debugging only).

3. LORE entry

If the session represents a substantive change-set in a project that maintains LORE.md (currently: ~/dev/research-team-sandbox/):

• Minor or major version bump (not patch)
• Multi-module change
• Long-running PR landing
• Leadership-conversation moment, pivot, or shift in direction

…add a dated entry under the current era following the LORE.md entry shape (What happened · Why it mattered · What it cost / opened · Reference). Otherwise: say "No LORE entry needed" by name.

4. TODOS.md

TODOS.md belongs to the sandbox repo (~/dev/research-team-sandbox/) — the RTS-N numbering and dated section convention only apply to sandbox-touching sessions.

For sandbox sessions: Capture any parked or deferred items as new RTS-N entries with:

• ID + priority (P2/P3 — P2 = should fix before next iteration, P3 = nice-to-have)
• Concrete file paths + line numbers if applicable
• Why it's deferred (not blocking, needs team agreement, etc.)
• Who raised it (yourself / reviewer / Copilot / etc.)

Increment from the highest existing RTS-N. Group under a dated section header ## YYYY-MM-DD — Deferred from <source> (<reviewer>).

For non-sandbox sessions (skills, standalone repos, Google Sheets work, etc.): there is no shared TODOS file. Park deferred items in the project memory's own "Outstanding" / "Open threads" / similar section — that's the right home for project-specific deferrals. Say "skipped — not a sandbox session; X deferrals captured in project_<slug>.md's Outstanding section instead" and name the file.

5. Git state

Report state per-repo when more than one repo was touched. For each:

• Current branch and HEAD commit SHA
• Status: clean / uncommitted-changes / unpushed-commits / no-git by design (valid status — some repos are intentionally local-only, e.g., Miro-internal content)
• Any parked local branches (committed work not yet pushed) — with brief explanation
• Open PRs touched in this session (URL + state: open/approved/merged)

If a session touched only one repo, report flatly without per-repo headers. If multiple, use a short bulleted list per repo so the reader can scan.

Do NOT push or open PRs unless the user explicitly asks (they may want to hold).

Backup verification (off-machine safety). Two cases, handled asymmetrically:

• Git remotes (flag, don't act). For any repo whose only off-machine copy is its git remote, treat unpushed commits as unbacked — flag them as "⚠️ unbacked: sole off-machine copy is the remote" (not the neutral "unpushed-commits") and surface the exact one-line push command. Flagging is the action; pushing / PR / merge stays the user's call (per the rule above) — push policy varies by repo (some are PR-only / no-direct-push / no-force-push), so never auto-push.
• Non-git personal files (run it, then report). Personal / non-repo files written this session that live outside git and rely on a cloud backup sync are a different risk: they have no git history to recover from, and a well-formed sync is one-way + additive (no deletes), so there's no "might want to hold" judgment. If such a sync is configured, run it as part of closeout and report the result — don't merely remind. The configured sync is the ccbackup alias (cc-logs-backup-sync.sh; mechanism + Drive legs 00–07 defined in local memory reference_workspace_backups). Run it whenever this session wrote to any synced folder (deliverables/, eod-recaps/, eow-summaries/, the memory dir, config-backup/, etc.) and confirm the output ends with Done <timestamp>. It's idempotent + additive, so running it when unsure is safe. (The Tue–Fri recap cron also runs it, but don't rely on that for a session that shipped closeout-worthy changes.)

If the session touched neither case, stay silent on backups — don't manufacture a line.

Resolve-now vs. defer-to-next-move (decision tree). "Flag, don't act" means don't auto-push — it does NOT mean defer the decision to next session. A flagged item is resolved within this closeout (done, or an explicit yes/no asked before the checklist completes); it must never silently graduate into the step-9 "next move." Apply this test to every candidate action:

Resolve BEFORE /close-chat completes if it passes ANY of:

• Durability / irrecoverable-loss — deferring risks losing work or state that can't be reconstructed (unbacked sole-copy commit, unsaved artifact, uncommitted diff about to be lost). Highest priority — overrides the "flag, don't act" reflex.
• In-context & bounded — fully doable now with what's already loaded, ~one command, and cheaper/less error-prone now (context is warm) than reconstructed cold next session.
• Cheap-and-authorized — low-risk and already authorized explicitly or by clear intent (e.g. "commit for future use" = durability intent → the commit isn't "for future use" until it's off-machine).

Genuine next move (defer) if ANY of:

• Needs an external dependency or another party (awaiting review, merge, data, team agreement).
• Requires a decision the user hasn't made and can't sensibly make at closeout.
• Is fresh work beyond wrap-up scope (new feature, refactor).
• The user explicitly said hold.

Outward/irreversible actions (push, PR, send) still need the user's yes — but ask for it now, during closeout, not next session. Matching the backup asymmetry above: non-git cloud-sync files → run it, then report; git remote (sole off-machine copy) → flag → ask → act on yes, all within closeout.

6. Open threads

A short list of what's not yet resolved:

• PR reviews awaiting response
• Follow-ups deferred to next session
• External blockers (team agreement needed, awaiting reviewer, awaiting data)
• Sessions parked mid-flight

7. Task list cleanup

• Use TaskList to read current state
• Mark stragglers completed if they actually completed
• Delete tasks that are no longer relevant (status: deleted)
• Leave open only what's genuinely carrying into a future session

8. Performance tracking

Tag the session against the user's live performance record. Earlier versions of this step tracked a single time-boxed improvement plan; when such a plan closes, the step does not retire with it — it becomes ordinary ongoing performance tracking against whatever the current objectives-of-record and review cadence are.

Read both from local memory (the user keeps private files there describing the current objectives, the review cadence, and the tagging taxonomy — locate them via MEMORY.md; the taxonomy the recap skills read lives at ~/dev/eod-recaps/taxonomy.local.md). The substance is intentionally not inlined here so this SKILL.md stays safe to ship in a public repo; the runtime resolves it at use-time.

• Objective tag — for any deliverable/decision this session produced, name which current objective it counts toward. Primary/secondary tagging is fine when work genuinely counts toward two — name both rather than forcing a single tag.
  • If a plan has closed and its successor objective set isn't yet agreed and recorded in the company system, say so by name and tag competencies only. Don't keep scoring against the closed plan, don't invent a replacement scheme, and don't report coverage percentages against something that no longer exists. Some tags from a closed plan may survive as named development areas rather than as graded progress — the taxonomy file states which; follow it rather than re-deriving it.
• Competency tag (durable) — the deliverables log is a durable evidence base that outlives any single plan or cadence, so it feeds review cycles beyond the current touchpoints (see its README.md → "Tiers & promotion cadence"). Apply the durable competency tags from the taxonomy file (C-Impact/Scope/Craft/Influence/Ownership — a placeholder pending a real leveling rubric) to any Deliverables-Log entry this session writes, so it's review-ready and not merely touchpoint-ready. Objective tags and competency tags are independent dimensions, and the competency dimension is the one that survives a plan or cadence change — when the objective side is unsettled, this is the tagging that still has to happen.
• Cadence proximity — days remaining to the next review touchpoint the cadence file names, plus any dated commitment inside an objective landing sooner. Flag any objective with no evidence at all this cycle — as thin coverage in words, not as a percentage.

• Record hygiene — conditional; do NOT fire this every session. Run the check only when at least one of these holds:

  1. the session earned an objective tag or wrote a Deliverables-Log entry,
  2. the next review touchpoint is roughly two weeks out or nearer, or
  3. a record gap is already known-outstanding (e.g. objectives agreed but not yet entered in the company system).

  Otherwise stay silent — an unconditional reminder becomes wallpaper, and a closeout that nags identically every time trains the reader to skim the step that matters. When it does fire: note whether this session's evidence is captured somewhere durable, and whether the objectives' own records are complete in the company system (due date and status, not just prose). A periodic judgment that exists only as conversation, or an objective with a blank due date, is an open thread — surface it in step 6 once, and don't draft the ask unless the user asks for it.

• Stakeholder-comms hygiene — if the session involved a stakeholder meeting or decision: were actions/decisions captured? Were the right people informed? Apply this especially to objectives that name stakeholder communication.
• Off-objective progress — note progress (or explicit lack of it) on anything the deliverables folder doesn't capture: course chapters, framework proposals, development-area practice.
• History stands — no retroactive re-tagging. Step-8 entries written while a prior plan was live were correct as of their date, and stay valid as historical record. When reading or rolling up past closeouts, recaps, or deliverables, leave their tags as written: don't translate them into the current scheme, don't restate them as current progress, and don't re-open grading that has closed. A scheme change applies forward only, from the date the plan closed.

When the plan-of-record itself changes (a plan closes, a cadence is replaced, objectives are agreed), the fix belongs in the taxonomy / cadence memory files, not in this skill — flag the mismatch and let the user re-scheme once, rather than quietly tagging against a stale scheme.

Skip explicitly if the session was purely tactical (debug, doc fix) with nothing worth tagging — but say it by name.

9. Next move

One concrete sentence describing the first thing the user should do when they pick up next session. Not a vague "continue the work" — a specific action with the names + numbers + paths already filled in.

First run the resolve-now-vs.-defer test (see step 5): anything that fails it — a durability/backup item, a bounded in-context action, a cheap-and-authorized step — is resolved during closeout, not parked here. The "next move" is only what genuinely defers (blocked, undecided, or fresh scope). A sole-copy unpushed commit must never be the next move.

Good examples:

• "Tomorrow morning: update the campaign batch config → export the per-segment CSVs → fire the scheduled sends → post the final daily status update."
• "Next session: rebase feature/example-branch onto main after PR #NN merges, then push and open the follow-up PR."
• "First move: read the reviewer's reply in the team channel before touching the refactor — they flagged a decision that affects the approach."

If there's no obvious next move (session was self-contained, no follow-up work), say "Next move: none — this session was self-contained." Honest is better than fabricated.

Output format

A single "Closing-chat checklist" message to the user, structured as a 9-item bulleted recap. Each bullet starts with the step name + a one-line summary of what was updated (or "skipped — <reason>"). End with the Next move line set apart visually so it stands out as the actionable handoff into the next session.

Example shape:

## Closing the chat

1. **Memory** — updated `project_<slug>.md` with shipped state, real numbers, parked work.
2. **Deliverables log** — wrote `2026-MM_<slug>.md` (75 lines, template followed).
3. **LORE** — added "<entry title>" under Era N; substantive (minor bump).
4. **TODOS** — captured RTS-N + RTS-N+1 as P3 follow-ups.
5. **Git + backup** — branch `<name>` at `<sha>`, pushed to PR #N (state: <state>); off-machine backup verified (or: ⚠️ N unpushed commits unbacked / run cloud sync for <files>).
6. **Open threads** — <bullet list>
7. **Tasks** — cleaned (N completed, M deleted, K still active for follow-up).
8. **Performance tracking** — counts toward <objective> (or: no agreed objective set yet — competency-only); competency tags <C-tags>; <X> days to <next touchpoint>; stakeholder-comms <state>.
9. **Next move** — <one concrete sentence with names, paths, numbers>

---

Ready to archive when you are.

If any step is skipped, say so explicitly with reason.

For Claude.ai web (not Claude Code)

A self-contained paste block lives in BOOTSTRAP.md alongside this file. Use it when working outside Claude Code (claude.ai, desktop app) where the memory + filesystem aren't directly accessible — paste the block into a fresh chat as the first message, then describe the session you're closing. The block recreates the checklist's expectations without depending on local files.

What NOT to do

• Don't open a PR, push, or merge during closeout unless explicitly asked.
• Don't write to memory or deliverables files speculatively — only update what was actually touched or shipped in this session.
• Don't fabricate "Open threads" or follow-ups that weren't real items.
• Don't add RTS-N entries that aren't grounded in something specific that came up (no busywork).
• Don't claim "no LORE entry needed" — say it by name with reasoning, per the LORE upkeep rule in CLAUDE.md.