wrapup: Claude Code session-end skill (SKILL.md)

A developer published a Claude Code session-end skill, "wrapup," defined in a SKILL.md file that runs a single-pass end-of-session checklist. The skill silently gathers git status, recent commits, worktrees and workstream files, then drafts a report covering state, learnings, commits, test coverage and open items, asking the user only one round-trip question to confirm or amend before finishing.

| name | wrapup | |---|---| | description | Session-end checklist — verify state saved, learnings captured, everything committed; then report | | allowed-tools | | | Read | Write | Edit | Bash | Grep | Glob | Run a single-pass wrap-up. Gather everything silently, propose a draft report with your best judgment, then let the user override or add in one round-trip. Don't walk through questions one at a time. - ls ~/.claude/workstreams/ .json — list workstreams; read any that look relevant to this session's work - For each git repo touched this session infer from conversation — typical candidates: cwd, ~/.claude , other project repos : - git status --short — uncommitted changes - git log --oneline -5 — recent commits so the report can list this session's commits - git worktree list — note unmerged worktrees Don't ask the user anything yet. For each section of the report, decide based on context — don't ask: - State — Is there a workstream that matches what we did? If so, propose updating it and do it inline if obvious . If the session was a one-off printing, lookups, ad-hoc fixes , say n/a . - Learnings — You propose these. Look back at the session for: corrections you received, unusual choices the user validated, non-obvious preferences, gotchas you hit, patterns worth repeating, or things to avoid next time. Draft the memory file s yourself based on what actually happened. If a learning is borderline you're not sure it's worth keeping, or you're not sure how to phrase the Why: / How to apply: , include it in the report and flag it for the user to confirm/edit/drop in the override step. If nothing meaningful surfaced, say none . Don't invent learnings that aren't grounded in this session, but DO surface ones the user didn't explicitly call out — that's the whole point. - Commits — List commits made this session. - Test coverage check — If this session added new functionality or non-trivial code not just docs, lookups, config tweaks, prints , verify tests were created for it. Specifically: - List the test files added/modified this session git diff --stat $MERGE BASE..HEAD -- ' test ' ' spec ' ' .feature' . - If the project uses BDD look for tests/features/ .feature or bdd conftest.py , confirm at least one BDD scenario was added — BDD coverage is easy to skip and worth a specific callout. - If new code shipped without tests, flag this in the report so the user can decide whether to backfill. - List the test files added/modified this session - Open items — Uncommitted changes, unmerged worktrees, branches that need pushing, PRs that need opening. Memory destinations per CLAUDE.md auto memory rules : - user .md — about who they are / how to collaborate - feedback .md — corrections or validated approaches include Why: and How to apply: lines - project .md — current initiatives, deadlines, decisions - reference .md — pointers to external systems or files All under ~/.claude/projects/<project /memory/ or the project-specific memory dir from the running CLAUDE.md . Add a one-line index entry to MEMORY.md . Don't save things derivable from code, git history, or existing CLAUDE.md content. Print the report format below . Then add ONE short question: Anything to add, change, or commit? Otherwise we're done. That's the only question. The user can: - Add a learning you missed → save it - Authorize a commit you flagged as uncommitted → make it - Tell you to update a workstream → do it - Say "done" → stop Don't loop unless the user explicitly asks for more iterations. Render as plain Markdown h2 + bold inline labels , NOT inside a fenced code block — the user reads this in the terminal and code blocks make it less readable. Example: Session wrap-up — <date State: <workstream s updated, or "n/a" . Learnings captured: - <learning name — <file path or one-line summary - or "none" Commits this session: - <repo : <sha <one-line message - or "none" Tests added: - <test file s + brief description - BDD: <feature file + scenarios, or "none" if BDD applies but wasn't added — flag this - or "n/a — no new code this session" Open items: - <unmerged worktree path s - <uncommitted work - <PRs to open / branches to push - or "none" That fenced block above is just to show the layout — when you actually print the report, do NOT wrap it in fences. Keep it under ~30 lines. - One round-trip, not four. Gather, decide, report, offer override. - Never auto-commit or auto-push without the user saying yes in the override step. - Propose learnings from session observation, not just from what the user said out loud. Borderline ones get flagged in the report for confirmation; obvious ones get saved. The bar is "grounded in something that happened this session," not "user explicitly told me to remember this." - If the session was trivial one-off lookup, simple print job , it's fine for every section to be n/a / none . Say so and stop. - Unlike save-state 's handoffs one new file per save, by design , wrapup's writes are already in-place and don't proliferate on repeat/back-to-back runs: a workstream update mutates existing fields no new file , and a learning is only saved if it's genuinely new — check the project's MEMORY.md /existing memory files first and update one in place rather than writing a near-duplicate when the same lesson resurfaces. So back-to-back /close / /wrapup calls in one session are safe as-is; nothing here needs the same "is this small and recent" gating save-state has.