session-end

Topics in the source

• session-end
• When to load
• Step 1 — handoff (opt-in)
• Step 2 — retrospective
• Step 3 — PR audit (when a queue exists)
• Auto-fire (opt-in)
• Workspace-aware paths

End-of-job wrap-up in three steps: an opt-in handoff, a retrospective that proposes skill updates from recurring friction, and a report on the session's PRs. CANARY: session-end-loaded-2026-05-20-4896c0a5-8ca7505c91dc34e6 The user types /session-end or says "wrap up", "we're done", "close this session". The opt-in auto-fire SessionStart hook runs (about once a week). The github skill is about to open a PR and the handoff marker is yes, so status/handoff.md is regenerated before the PR commit. Mid-job is too early: the retrospective needs a complete arc to scan. First, if this session adopted or locked an architecture decision, make sure the spec and plan say so (arsenal/project/ /spec.md + plan.md, or status/specification.md + status/plan.md), or seed a queue task for it. A blocking spec divergence found this session becomes a queue task too. An idea or decision raised this session but missing from status/ideas.md is a handover item. The handoff is a snapshot the next session overwrites; the spec, plan and queue are the ledger. Then read the host repo's CLAUDE.md for the marker: | Marker | Behavior | |---|---| | | Generate status/handoff.md from the session, commit it. | | | Skip (

This is an excerpt. Refer to the complete source and its current requirements.