# Session Close — the end-of-session save sequence — a Claude Code skill *Part of the Wasser AI Academy skills library. Free to use.* **What it is:** an ordered save routine that runs when a work session wraps up, so the useful parts of that session land in your notes instead of dying in the chat transcript. It writes to your daily note, files detail into the owning project note, updates one line in your context file, syncs your active-work board, and optionally records a lesson or two. **Install:** save this file as `~/.claude/skills/session-close/SKILL.md` (create the folder). Claude Code picks it up automatically. Using Codex or another agent? Paste the content into your `AGENTS.md`. --- Here is the problem this solves. You finish a good session — a decision made, a thing built, a bug understood — and none of it is written down anywhere your next session will look. The chat scrolls away. A week later you can't remember why you made the call, or that you made it at all. The fix is boring and it works: at the end of a meaningful session, run the same six steps every time, in the same order. Run it without being asked when a session ends, or on command (`/save`). Use ISO dates (`YYYY-MM-DD`) everywhere, read from the environment — never guess the date. A note on the placeholders below. This skill assumes an Obsidian-style vault with a few conventional files: a **daily note** per day, **project/area notes** (hubs) that own a topic, a single always-loaded **context file** that a session-start hook injects, and an **active-work board**. Point the paths at your own vault's version of each. The rules matter more than the filenames. --- ## 0 — Triage: is this session even worth saving? A session is **meaningful** if any of these happened: - A note or code file was created or edited. - A decision was made — direction, pricing, killing or parking work, a new constraint. - A non-trivial task ran — research, a build, a debug, a deploy. - The user corrected you or repeated an instruction. If none of these hold — pure Q&A, a lookup, a chat that produced nothing durable — **write nothing and say so**: "Trivial session, nothing to save." That is the correct outcome, not a skipped step. A manufactured daily entry for an empty session is noise, and it causes duplicate-session bloat down the line. If it's meaningful, run steps 1 through 6 **in order**. The order is deliberate: cheapest and most-always-applies first (daily note), most judgment-heavy last (lessons). --- ## 1 — Append to today's daily note **Prefer appending to today's existing daily note over creating a new file.** It almost always already exists. Read it first, then add to it. Add **one** bullet for this session under the sessions heading: ``` - HH:MM — → [[owning note]] ``` - Use 24-hour local time. - For a substantial session, a fuller bullet with sub-bullets (the specific commits, the gotcha you hit, the decision) is better than a terse one. Write enough that you'd understand it cold in a month. - **Do not create a second bullet for a session you already logged.** If you're re-running the close on a session you partly saved, edit the existing bullet instead of adding a duplicate. Duplicate session bullets are the most common form of daily-note rot. - Wiki-link every note you touched: `[[Project Name]]`. --- ## 2 — File the detail into the note that owns it If the session produced durable detail — a decision record, a spec, call notes, a description of the thing you built — save or append it to the note that owns that topic (its hub). - **Check whether a hub note already exists before creating one.** Prefer appending and linking over spawning a new file. A vault full of near-duplicate notes is worse than a vault with fewer, fuller ones. - Add wiki-links to related notes: `Related: [[Other Project]]`. - Add consistent tags so the note is findable later: a project tag (`#project/name`), a topic tag (`#topic/...`), and a type tag (`#type/decision`, `#type/insight`, `#type/action`). - If you can't tell where it belongs, file it in your inbox note (`Inbox/YYYY-MM-DD.md`) rather than guessing wrong. Sorting it later is cheap; finding a misfiled note is not. - If you create or edit a hub note, do the timestamp bump (step 6) in the same edit. --- ## 3 — One line to your context file, then reconcile the snapshot Your context file is the note a session-start hook loads into every new session. It has a strict job: be a **true snapshot of the present**, small enough to fit the injection budget. Two rules keep it from rotting. **3a — Add exactly one line.** At the top of the recent-notes list (newest first), append **one** entry, roughly 30 words or fewer: ``` - YYYY-MM-DD — . → [[hub]] [[hub2]] ``` - **One line, not a paragraph.** The detail already lives in the daily note (step 1) and the hub (step 2). The context file only gets the pointer. This is the rule people break first, and paragraph entries are exactly how a context file grows past its injection budget and starts silently truncating — at which point the hook is feeding your next session half a file. - **One** entry per session. Consolidate; don't list five. - Only write an entry for a genuine milestone or a decision worth recalling. A minor edit belongs in the daily note only. - The recent-notes list is a **rolling ~30-day window**. When you add today's line, check the bottom: cut anything older than 30 days and paste it into an archive note. Left alone, this section is what bloats the file. - Do not turn the top-of-file summary line into a changelog. It is capped. History goes to an archive note, never onto that line. **3b — Reconcile the snapshot.** This is the step everyone skips, and skipping it is how a context file ends up lying. After adding your one line, re-read the standing sections for whatever project this session touched (active projects, goals, status). If the session's outcome contradicts a line that's already there, **rewrite that line in place** — replace it, don't annotate it. The context file is a snapshot; every line must be true today. Append-only maintenance is a documented failure mode: a project can sit described as "not shipped yet" for a month while it's live and selling, purely because nobody rewrote the old line when the new one went in. (Note the split: annotate-don't-delete history belongs in your hubs. The context file is the one place you overwrite instead of annotate, because its whole value is being current.) --- ## 4 — Sync the active-work board Your board is an **active-work board, not a backlog.** The distinction is the whole point. A backlog holds everything you might ever do; a board holds only what you're touching now or next. Boards that quietly become backlogs are useless — one bloated to over a hundred stale items once, purely because closures lagged intake. Caps are what prevent that, and caps only hold if you enforce them **every** session. Organize it into categories by project or area, each with a hard cap of **≤5 active items**. Then sync it to reality: 1. **Completed this session** → flip the checkbox on the board *and* in the source note (keep both in sync), then **move the board entry to a "Recently completed" section** with the date and a one-line result. Don't leave a checked box sitting in an active category — that's an orphan, and orphans are the number-one source of board bloat. 2. **New active work that surfaced** → add it under its category, respecting the ≤5 cap. If adding it would breach the cap, first close, park, or demote something. Flag only genuinely urgent items. Overflow goes to a parked sub-list (uncapped, doesn't count toward five) or down to the project note's backlog. **Never silently exceed the cap.** Non-active, not-for-now work goes to the project note, not the board. 3. **Stale items** → an item untouched for **14 days** gets a `(stale — review or kill)` flag. Untouched for **30 days**, it's demoted off the board to its project note — and you tell the user what moved, so nothing vanishes silently. 4. **Orphaned checkboxes** → if a hub picked up a shipped/dead/parked annotation this session, close its board items in the *same* pass. Never leave a live checkbox pointing at a resolved project. 5. **Trim** the "Recently completed" section to a rolling ~7-day window if it runs long. 6. **Bump the board's own `Last updated:` line.** Do not skip the cap check to save a minute. The minute you save is repaid with interest the day the board is unusable. --- ## 5 — Retrospective: zero to three lessons (pull-based) If the session was meaningful, you *may* record 0–3 lessons about **how the work went** — not what was built (your notes already have the what). Write one when: - The user corrected you or repeated an instruction. - You missed a chance to be proactive — should have surfaced something, checked memory, caught a contradiction, flagged drift. - A tool or approach was slow, wrong, or had a gotcha worth remembering. - You learned something durable about how this person wants to work. **Placement matters more than it looks.** If a session-start hook extracts lessons from a specific heading downward, then a lesson written *above* that heading is invisible to every future session. Insert new entries **under** the "Recent" heading, newest on top — never above it. This is a real failure mode, not a hypothetical: lessons placed above the marker were silently never read. Before adding one, scan the existing recent lessons for a duplicate. If the same lesson is already there, **bump its recurrence count** instead of writing a near-copy. A lesson that keeps recurring is a stronger signal than three separate phrasings of it. Zero lessons is a valid outcome. If the session taught nothing durable about *how* you work, write none. And keep this step pull-based: run it as part of the full save, or on demand when the user asks you to "scrape this session for lessons." Don't force a retrospective at every plain session end — an unprompted "here's what I learned" at the wrong moment interrupts more than it helps. --- ## 6 — Bump the timestamps For **every** hub note you created or edited this session, keep the two dated lines under the title current: ``` **Created:** YYYY-MM-DD **Last updated:** YYYY-MM-DD ``` - Edited a hub → bump `Last updated:` to today, in the same edit. A stale-note checker reads this line; without the bump it can't tell fresh from stale. - Created a hub → add both lines. - Missing `Created:` → use the best-known date (first mention in a daily note, earliest in-note reference); if there's no signal, use today and mark it estimated. - Even a small annotation counts as an edit — bump the line. --- ## The short version - **No manufactured save for a trivial session.** Declare it trivial and stop. - **No duplicate daily entries** for one session — edit the existing bullet. - **No paragraphs in the context file**, no changelog on the summary line, one recent-notes entry that rotates out at 30 days. - **Reconcile the snapshot** — rewrite stale lines in the context file, don't annotate them. - **Enforce the board caps every session** — no category over five active, no orphaned checkboxes from resolved work. - **No lesson above the "Recent" marker** — the hook won't see it. - **No hub edit without a `Last updated:` bump.** Run 1 → 6 in sequence. When you're done, give a 3-4 line summary of what was saved and where, with the file paths, plus anything you flagged on the board.