Session wrap-up. Use when Ane types /wrap-up to close a session. Gathers git, errors, and pending actions, delivers a concise status report, then commits and pushes pending work, and offers opt-in post-commit follow-ups (skill improvements, skill-fit signals, learning capture). Pass "report" for a r

Session Wrap Up A session end workflow in phases, not a single parallel check. Run them in order: 1. Preflight — confirm the repo and capture the branch. 2. Gather (read only checks 1 to 6) — collect status; write nothing. 3. Report — deliver one consolidated status checklist. 4. Commit and push (gated, autonomous) — record side effects, then commit pending work. 5. Optional follow ups (opt in, batched into one prompt) — skill and learning loops. 6. Continuation handoff (automatic, gated on open work) — write the prompt that starts the next session. Report only mode. If Ane invokes /wrap up report , /wrap up report only , or asks for status only, run phases 1 to 3 then STOP. Do not write, commit, or run any follow up, and do not write a handoff. Date. Use the current date from the session environment. Never guess it. Phase 1 — Preflight The thread is now closed. From this point, park every new question, explainer request and follow up ask in the Phase 6 handoff rather than answering it in session. Say so in one line when it happens: Parked for the next session: <ask . Ane can override by repeating the ask, and then you answer it. Reason (2026 07 30 /improve system Run 4): across five consecutive logged sessions the thread itself closed at 190k–227k and the whole overage came from post decision Q&A, one extra check, and the wrap up loops. Closing costs about 50k; answering new asks inside the close out is what doubles it. Run git rev parse git dir 2 /dev/null . If it fails (not a git repository), skip the git, harness, and commit sections. Run only checks 3 and 4, deliver a short report, and end with: Otherwise capture the branch once: git branch show current . Hold it as the expected branch for the branch guard in Phase 4, and show it in the report header. Capture every repo the session wrote to, not only the working directory. Before moving to Phase 2, list the repos this session actually touched: the working directory, plus any other repo a file was written or committed to. Hold that set as the repo set , and run check 1, the Phase 4 gates, and the commit against each repo in it, labelling each block with its repo name in the report. git status reads the current directory only, so a session that produced its deliverables in a project repo and then wrapped up from the work folder reports a clean tree while real work sits exposed somewhere else. Evidence (2026 08 01, it demo followup and system synthesis ): the whole session's output landed in 1. Ane's PROJECTS/AI in IPPF EN 2026/MY MEL AI SYSTEM DEMO , including Ane's hand edited canonical .docx sitting untracked and one file the agent had written that existed nowhere else; the work folder repo was clean and would have reported "safe to close" on its own. A repo with no remote is not a defect to fix . The three local only repos guarding 1. Ane's PROJECTS exist to survive OneDrive reverts, so report no remote by design , skip the push, and never offer to add an origin. A read only probe into another repo in the set can be blocked, and the block is usually pointing at cheaper evidence. The edit preservation guard judges a command on the folders it names, so git C <other repo config get ... is refused when that repo holds one of Ane's hand edited artefacts, even though the command writes nothing. Do NOT reach for accept to satisfy a status read: the guard is correct that the artefacts changed, and clearing a block to produce a report line spends Ane's protection on bookkeeping. Ask instead what already proves the fact. A harness check that went green this session over exactly that condition is stronger evidence than re reading the file by hand, because it was computed rather than eyeballed. Evidence (2026 09 10): a wrap up read of Antwerphouse 's user.email , confirming that a deliberate temporary revert had been restored, was blocked on two hand edited .docx files in that repo; check git identity by content had already asserted the same condition and was green, so the check was the answer and the read was never needed. Where nothing already asserts it, isolate the probe in its own command: the blocked call that day was batched with the desktop sync and handoff status checks and took both down with it. Resume check — never run a full wrap up twice. If a wrap up already ran in this session and stopped at the Phase 4 harness gate, this invocation is a RESUME, not a fresh close out. Say Resuming wrap up at the harness gate. then run ONLY: the harness (Phase 2 check 2), the Phase 4 gates, commit and push, and Phase 6. Skip Phases 2 and 3 otherwise, and skip Phase 5 unless Ane asks for it. Their findings have not changed, and re deriving them is the largest avoidable cost in the close out: the 2026 07 28 local analyst mirror freshness check row logged two wrap up passes plus the cost log reconciliation, which almost exactly doubled the session spend. A resume is one harness run and a commit, not a second session review. Phase 2 — Gather (read only checks) 1. Git status Run git status short . For unpushed commits, run git log oneline "@{u}.." 2 /dev/null . If the branch has no upstream ( git rev parse @{u} fails), say so explicitly: nothing is pushed yet, and the push step will set u . Do not report "all pushed" when there is no upstream. Report uncommitted files (count + list), unpushed commits (count + list), and the current branch. If both are clean, state that clearly. Committed and pushed is not the same as landed. git status and @{u}.. both measure against the branch you happen to be on, so a session whose work sits on a feature branch reports nothing uncommitted, all pushed while the branch that actually gets consumed still holds the old content. This matters whenever the session's purpose is what some other surface reads: a mirror, a published default branch, npx skills add (which installs from the default branch, not from yours), a deploy, or a release. So when the session's work was meant to change what a remote publishes, verify against origin/<default branch rather than the local checkout, and state in the report which branch you checked. Evidence (2026 08 03, github migration runbook and preflight cleanup ): two repos were on a wave0 skill fixes branch; every cleanup commit reported success while origin/main still carried all 25 files the session had removed and the personal project name in 5 more. Both repos read clean at wrap up. Had the IPPF mirror run that day it would have copied everything the session existed to remove. Cheap check, two lines: git ls tree r name only origin/main <path that should be gone wc l and git rev list left right count origin/main...HEAD . The same check runs in the other direction: the artefact landed, its dependency did not. A session can ship a consumer to its default branch correctly and still leave that consumer broken, because the module it imports is sitting on an unmerged feature branch in a different repo. Every local check passes — both trees clean, both branches pushed, the harness green — because the working tree has the branch checked out and the import resolves. So when the session shipped something that imports code it also wrote, verify the import target on its own origin/<default branch , not just the artefact. One line: git show origin/main:<module path grep c "def <the new function " , and a 0 means the consumer is live against code nobody else has. Evidence (2026 08 03, wave 2 office review pass ): the office review pass skill landed on personal skills main and was installed globally, while the render review it imports existed only on wave2 office review pass in the work folder repo; a checkout of main got a skill whose read mode raised on import. The fix is to merge before closing, not to leave it for the next session's first step — a handoff instruction is not a working default branch. A clean tree does not prove no hijack happened. The Phase 4 branch integrity gate runs only when there is something to commit, and check branch integrity.sh inspects only commits ahead of origin/main . A background loop that commits and pushes in one motion defeats both at once: nothing is uncommitted, nothing is ahead, and the gate reports Clean while never running. On 2026 07 28 commit 622325d landed on main at 21:16:57 unauthored by that session, and pushed the session's own two commits to origin as a side effect; at wrap up the tree was clean and 0 commits were ahead, so nothing flagged it. So in this check, always list the commits dated inside the session window regardless of push state ( git log 10 format="%h %ad %s" date=format:"%H:%M:%S" ) and mark any whose subject the session does not recognise as ⚠️ Unattributed commit under ERRORS. Report it, do not act on it: the commit is already on origin and reverting it from a wrap up is more dangerous than surfacing it. See the reference loop guard gap markerless memory. 2. Test harness (project aware) If tests/run tests.py exists in the repo root AND the session touched a text file the harness covers (markdown, code, config), run python tests/run tests.py and include the result. Run it through the plain Bash tool, never only through context mode's sandbox: the sandbox shell is UTF 8 and masked two cp1252 UnicodeEncodeError failures (Wave 3 and Wave 5 2, 2026 08 04) that were red in Ane's own terminal. "Touched" means edited at any point this session, whether the change is still uncommitted or already committed. If it passes, report ✅ Harness N/N . If it fails, list each failure as ⚠️ HARNESS: and recommend /test for detail. If the harness file does not exist, skip this check silently — most repos have no MEL harness. Do not gate this check on a dirty working tree. A clean tree means the work is committed, not that it is correct. On 2026 07 28 the tree was clean at wrap up and the harness was red: an edit had gone into claude ai shareable export/ (a generated mirror) instead of the canonical root file, and check claude ai sync caught the divergence. Gating on uncommitted files would have closed the session with a red harness and a broken claude.ai export already pushed to origin. Re run a failed sync or mirror check once before acting on it. Checks that compare two copies of a file (skill cache against clone, generated mirror against canonical) fail transiently when a parallel process is mid write. On 2026 07 28 skill repo:local cache content matches clone reported drifted: ann, vi while a background npx skills add was propagating a just pushed commit; the two files were already byte identical and the clone was already pushed. Acting on that check's own failure advice, "push to personal skills", would have been the wrong move. Re run the harness once: if the failure clears, it was a race. If it persists, diagnose which side is stale BEFORE copying anything, because the copy overwrites the newer side (see the reference skills mirror stale clone gotcha memory). 3. Recent errors Scan this conversation for error messages, failed commands, or unresolved issues identified but not fixed: stack traces, "error:", "failed", "TODO", explicit "I'll fix this later" statements. 4. Pending actions Identify anything Ane said she would do or left open: Files to review or send Follow up tasks mentioned Decisions deferred Any explicit "next steps" not yet taken 5. Uncommitted changes risk If there are uncommitted files, run git diff stat to assess what is at risk of being lost. 6. Desktop / claude.ai export drift (project aware) If scripts/check desktop sync.py exists in the repo root, run python scripts/check desktop sync.py . This surfaces claude.ai Desktop project files that drifted since the last upload (the claude.ai project has no file API, so this surface is always a manual re upload). If it reports [DRIFT] ,