wrap-uplisted

End-of-session handler that first checks whether the current session's plan is actually complete. If complete: refresh repo, run quick retrospective, clean gone branches, and emit a forward-looking follow-up prompt. If incomplete: skip cleanup and emit one or more `cd`-into-worktree blocks paired with ready-to-paste resume prompts so the unfinished work can be picked up cold in a new session.
JacobPEvans/claude-code-plugins · ★ 2 · AI & Automation · score 68

Install: claude install-skill JacobPEvans/claude-code-plugins

# Post-Session Wrap-Up > **State warning**: Branch state, remote tracking, TaskList contents, and plan > checklist state all change between invocations. Re-run every git/gh command > and re-call `TaskList` from Step 0; never trust prior outputs from this > conversation. `/wrap-up` has two paths. Step 0 decides which one runs. | Step 0 outcome | Path | | ------------------------ | ----------------------------------------------------------------- | | Plan complete OR no plan | **Path A** — refresh repo, retrospective, clean branches, follow-up prompt | | Plan incomplete | **Path B** — emit resume blocks; skip Path A cleanup entirely | The `purge-pr` focused mode (bottom of this file) bypasses Step 0 entirely. ## Step 0: Determine session state There are two distinct things to keep straight here: 1. **The plan file itself** — a real markdown file at `<HOME>/.claude/plans/<slug>.md`. Plan mode writes it; the assistant reads and edits it during implementation; it persists on disk after the session ends. The file is the canonical store of the plan's *content* — the checklist items, the context, the files to change. Step 0b reads it. 2. **The binding from session → plan file** — i.e. *which* of the many files under `~/.claude/plans/` is the one this session is working against. That binding is the hard problem under parallelism, because many sessions may be writing files in