{"slug": "wrapup-claude-code-session-end-skill-skill-md", "title": "wrapup: Claude Code session-end skill (SKILL.md)", "summary": "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.", "body_md": "| name | wrapup | \n|---|---|\n| description | Session-end checklist — verify state saved, learnings captured, everything committed; then report | \n| allowed-tools |  | \n\n| Read | Write | Edit | Bash | Grep | Glob | \n\nRun 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.\n\n- `ls ~/.claude/workstreams/*.json` — list workstreams; read any that look relevant to this session's work\n- For each git repo touched this session (infer from conversation — typical candidates: cwd, `~/.claude` , other project repos):\n  - `git status --short` — uncommitted changes\n  - `git log --oneline -5` — recent commits (so the report can list this session's commits)\n  - `git worktree list` — note unmerged worktrees\n\nDon't ask the user anything yet.\n\nFor each section of the report, decide based on context — don't ask:\n\n- **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` .\n- **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.\n- **Commits** — List commits made this session.\n- **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:\n  - List the test files added/modified this session (`git diff --stat $MERGE_BASE..HEAD -- '*test*' '*spec*' '*.feature'` ).\n  - 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.\n  - If new code shipped without tests, flag this in the report so the user can decide whether to backfill.\n- List the test files added/modified this session (\n- **Open items** — Uncommitted changes, unmerged worktrees, branches that need pushing, PRs that need opening.\n\nMemory destinations (per CLAUDE.md auto memory rules):\n\n- `user_*.md` — about who they are / how to collaborate\n- `feedback_*.md` — corrections or validated approaches (include**Why:** and**How to apply:** lines)\n- `project_*.md` — current initiatives, deadlines, decisions\n- `reference_*.md` — pointers to external systems or files\n\nAll 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`.\n\nDon't save things derivable from code, git history, or existing CLAUDE.md content.\n\nPrint the report (format below). Then add ONE short question:\n\nAnything to add, change, or commit? Otherwise we're done.\n\nThat's the only question. The user can:\n\n- Add a learning you missed → save it\n- Authorize a commit you flagged as uncommitted → make it\n- Tell you to update a workstream → do it\n- Say \"done\" → stop\n\nDon't loop unless the user explicitly asks for more iterations.\n\nRender 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:\n\n```\n## Session wrap-up — <date>\n\n**State:** <workstream(s) updated, or \"n/a\">.\n\n**Learnings captured:**\n- *<learning name>* — <file path or one-line summary>\n- (or \"none\")\n\n**Commits this session:**\n- `<repo>`: `<sha>` <one-line message>\n- (or \"none\")\n\n**Tests added:**\n- <test file(s) + brief description>\n- BDD: <feature file + scenarios, or \"none\" if BDD applies but wasn't added — flag this>\n- (or \"n/a — no new code this session\")\n\n**Open items:**\n- <unmerged worktree path(s)>\n- <uncommitted work>\n- <PRs to open / branches to push>\n- (or \"none\")\n```\n\n(That fenced block above is just to show the layout — when you actually print the report, do NOT wrap it in fences.)\n\nKeep it under ~30 lines.\n\n- One round-trip, not four. Gather, decide, report, offer override.\n- Never auto-commit or auto-push without the user saying yes in the override step.\n- 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.\"\n- 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.\n- Unlike `save-state` 's handoffs (one new file per save, by design), wrapup's writes are already\nin-place and don't proliferate on repeat/back-to-back runs: a workstream update mutates existing\nfields (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\nwhen the same lesson resurfaces. So back-to-back`/close` /`/wrapup` calls in one session are safe\nas-is; nothing here needs the same \"is this small and recent\" gating`save-state` has.", "url": "https://wpnews.pro/news/wrapup-claude-code-session-end-skill-skill-md", "canonical_source": "https://gist.github.com/paultparker/ba31163d92edebe3a2337b1c0a9130b9", "published_at": "2026-11-01 15:55:40+00:00", "updated_at": "2026-11-01 16:21:29.815925+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-products"], "entities": ["Claude Code", "Anthropic"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/wrapup-claude-code-session-end-skill-skill-md", "markdown": "https://wpnews.pro/news/wrapup-claude-code-session-end-skill-skill-md.md", "text": "https://wpnews.pro/news/wrapup-claude-code-session-end-skill-skill-md.txt", "jsonld": "https://wpnews.pro/news/wrapup-claude-code-session-end-skill-skill-md.jsonld"}}