wrap-up

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):

1. Run git status in each repo directory that was touched during the session
2. 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.

5. 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):

1. ✅ Skill gap: Cost estimates were wrong multiple times → [CLAUDE.md] Added token counting reference table

2. ✅ Knowledge: Worker crashes on 429/400 instead of retrying → [Rules] Added error-handling rules for worker

3. ✅ Automation: Checking service health after deploy is manual → [Skill] Created post-deploy health check skill spec

---

No action needed:

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

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