| name | wrap-up |
| description | Use when user says "wrap up", "close session", "end session", "wrap things up", "close out this task", or invokes /wrap-up — runs end-of-session checklist for shipping, memory, and self-improvement |
Session Wrap-Up
Run four phases in order. Each phase is conversational and inline — no
separate documents. Local, reversible actions (commits, task updates, memory
writes) auto-apply. Outward-facing or hard-to-reverse actions — pushing to a
remote and moving/renaming files — are proposed, then applied only after the
user confirms. Present a consolidated report at the end.
Phase 1: Ship It
Commit (auto — local and reversible):
- Run
git status in each repo directory that was touched during the session
- If uncommitted changes exist, auto-commit with a descriptive message. If on the
default branch, create a session branch first rather than committing straight to main.
Push (confirm first):
3. List the commits that would be pushed and to which remote/branch, then ask the
user to confirm before pushing. Do not push without explicit confirmation.
File placement check (confirm moves/renames first):
4. If any files were created or saved during this session:
- Verify they follow your naming convention and are in the correct subfolder
- List every proposed rename/move (from → to) and apply them only after the
user confirms. Never silently rename or relocate files.
- If any document-type files (.md, .docx, .pdf, .xlsx, .pptx) were created at the
workspace root or in code directories, include them in the proposed-moves list
(to the docs folder) — same single confirmation gate.
Deploy:
6. Check if the project has a deploy skill or script
7. If one exists, run it
8. If not, skip deployment entirely — do not ask about manual deployment
Task cleanup:
9. Check the task list for in-progress or stale items
10. Mark completed tasks as done, flag orphaned ones
Phase 2: Remember It
Review what was learned during the session. Decide where each piece of
knowledge belongs in the memory hierarchy:
Memory placement guide:
- Auto memory (Claude writes for itself) — Debugging insights, patterns
discovered during the session, project quirks. Tell Claude to save these:
"remember that..." or "save to memory that..."
- CLAUDE.md (instructions for Claude) — Permanent project rules,
conventions, commands, architecture decisions that should guide all future
sessions
.claude/rules/ (modular project rules) — Topic-specific instructions
that apply to certain file types or areas. Use paths: frontmatter to scope
rules to relevant files (e.g., testing rules scoped to tests/**)CLAUDE.local.md (private per-project notes) — Personal WIP context,
local URLs, sandbox credentials, current focus areas that shouldn't be
committed@import references — When a CLAUDE.md would benefit from referencing
another file rather than duplicating its content
Decision framework:
- Is it a permanent project convention? → CLAUDE.md or
.claude/rules/
- Is it scoped to specific file types? →
.claude/rules/ with paths:
frontmatter
- Is it a pattern or insight Claude discovered? → Auto memory
- Is it personal/ephemeral context? →
CLAUDE.local.md
- Is it duplicating content from another file? → Use
@import instead
Note anything important in the appropriate location.
Phase 3: Review & Apply
Analyze the conversation for self-improvement findings. If the session was
short or routine with nothing notable, say "Nothing to improve" and proceed
to Phase 4.
Auto-apply all actionable findings immediately — do not ask for approval
on each one. Apply the changes, commit them, then present a summary of what
was done.
Finding categories:
- Skill gap — Things Claude struggled with, got wrong, or needed multiple
attempts
- Friction — Repeated manual steps, things user had to ask for explicitly
that should have been automatic
- Knowledge — Facts about projects, preferences, or setup that Claude
didn't know but should have
- Automation — Repetitive patterns that could become skills, hooks, or
scripts
Action types:
- CLAUDE.md — Edit the relevant project or global CLAUDE.md
- Rules — Create or update a
.claude/rules/ file
- Auto memory — Save an insight for future sessions
- Skill / Hook — Document a new skill or hook spec for implementation
- CLAUDE.local.md — Create or update per-project local memory
Present a summary after applying, in two sections — applied items first,
then no-action items:
Findings (applied):
-
✅ Skill gap: Cost estimates were wrong multiple times
→ [CLAUDE.md] Added token counting reference table
-
✅ Knowledge: Worker crashes on 429/400 instead of retrying
→ [Rules] Added error-handling rules for worker
-
✅ Automation: Checking service health after deploy is manual
→ [Skill] Created post-deploy health check skill spec
No action needed:
- Knowledge: Discovered X works this way
Already documented in CLAUDE.md
Phase 4: Publish It
After all other phases are complete, review the full conversation for material
that could be published. Look for:
- Interesting technical solutions or debugging stories
- Community-relevant announcements or updates
- Educational content (how-tos, tips, lessons learned)
- Project milestones or feature launches
If publishable material exists:
Draft the article(s) for the appropriate platform and save to a drafts folder.
Present suggestions with the draft:
All wrap-up steps complete. I also found potential content to publish:
- "Title of Post" — 1-2 sentence description of the content angle.
Platform: Reddit
Draft saved to: Drafts/Title-Of-Post/Reddit.md
Wait for the user to respond. If they approve, post or prepare per platform.
If they decline, the drafts remain for later.
If no publishable material exists:
Say "Nothing worth publishing from this session" and you're done.
Scheduling considerations:
- If the session produced multiple publishable items, do not post them all
at once
- Space posts at least a few hours apart per platform
- If multiple posts are needed, post the most time-sensitive one now and
present a schedule for the rest
