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

> Source: <https://gist.github.com/paultparker/ba31163d92edebe3a2337b1c0a9130b9>
> Published: 2026-11-01 15:55:40+00:00

| 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.