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. All phases auto-apply without asking; present a consolidated report at the end.
Phase 1: Ship It
File placement check:
- If any files were created or saved during this session:
- Verify they follow your naming convention
- Auto-fix naming violations (rename the file)
- Verify they're in the correct subfolder per your project structure
- Auto-move misplaced files to their correct location
- If any document-type files (.md, .docx, .pdf, .xlsx, .pptx) were created at the workspace root or in code directories, move them to the docs folder if they belong there
Deploy: 3. Check if the project has a deploy skill or script 4. If one exists, run it 5. 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. Usepaths:frontmatter to scope rules to relevant files (e.g., testing rules scoped totests/**)CLAUDE.local.md(private per-project notes) — Personal WIP context, local URLs, sandbox credentials, current focus areas that shouldn't be committed@importreferences — 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/withpaths: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
@importinstead
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