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

| 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), sayn/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 theWhy: /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, saynone . 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 orbdd_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 (includeWhy: andHow 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'sMEMORY.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" gatingsave-state has.