wrap-up — verify state, report, then UMS

Close out a work session cleanly: confirm where everything actually landed, report it with clickable links (surfacing anything still open), and capture what was learned before the context is gone.

Synonyms: done — a plain “are we done?” entry point that routes here; and merged — routes here too, and can name the just-merged PR to anchor the summary (e.g. /merged #74). (Distinct from post-merge, which wraps up a single just-merged PR rather than the whole session.)

When this fires

  • “wrap up”, “wrap up the session”, “finish up”, “let’s close out”, “done”, “all done”, “are we done?”
  • The end of a multi-PR / multi-issue session.

Procedure

1. Verify state — never assume

Don’t report from memory or assume a merge did/didn’t happen — query each thing fresh (this is the never assume; always verify rule applied to closing out). Commands below are annotated with their abstract operation token — resolve to your model’s tool via tool-mappings.md instead of the gh command shown if this session doesn’t have gh:

gh pr list --state open --json number,title,headRefName,author,mergeable,mergeStateStatus,comments \
  --jq '.[] | "#\(.number) [\(.author.login)] \(.title) [\(.mergeable)]"'   # LIST_PRS
gh issue list --state open --json number,title --jq '.[] | "#\(.number) \(.title)"'   # LIST_ISSUES
git status --short                         # uncommitted work?
git worktree list                          # leftover worktrees (agent isolation / session-lock)?
git log --oneline -5 origin/main           # what actually landed on main
  • For every PR/issue you touched, confirm its real state with gh pr view <N> --json state,mergedAt (or gh issue view; abstract tokens: VIEW_PR / VIEW_ISSUE). A PR you think you left open may have been merged by the user, and vice-versa.
  • If the session touched other repos (e.g. an upstream dependency), check those too — gh pr list --repo <owner>/<repo> --state open --json number,title,headRefName,author,mergeable,mergeStateStatus,comments (LIST_PRS).
  • Merge conflict sweep. Before closing out, check every open PR’s mergeable field. For each PR with mergeable == "CONFLICTING" or "UNKNOWN" (see resolve-conflicts, “Verify before you act” — UNKNOWN can mean GitHub hasn’t finished computing yet), verify with git merge-tree --write-tree origin/main origin/<branch> (git ≥ 2.38) before acting, then check claim status (most recent comment) and fix confirmed conflicts using the cascade procedure in post-merge step 1.5 (claim → isolated worktree → merge main → resolve-conflicts skill → push → unclaim). Don’t leave conflicting PRs behind when wrapping up — they block whoever works the queue next.

2. Surface anything still open or dangling

List, don’t bury:

  • Open PRs — every one, linked. Flag any you didn’t expect (e.g. a @claude-bot-opened PR) instead of silently passing over it.
  • Open issues, uncommitted working-tree changes, unmerged local branches, and any deferred follow-up issues filed this session.
  • Leftover git worktrees — agent isolation and session-lock leave worktrees behind (esp. ones whose PR already merged). Flag them and offer to run clean-worktrees (cw) to sweep the dead ones.
  • Never report “all done” while something is open — name it and say whose call it is (e.g. “PR #25 is the bot’s; yours to merge or close”).

3. Report a linked final summary

  • A table of the session’s PRs/issues with outcomes, where every PR/MR/issue number is a markdown link (repo policy — never a bare #N).
  • A Pacific-time timestamp (TZ=America/Los_Angeles date "+%Y-%m-%d %H:%M %Z"; the explicit TZ enforces PT on a machine set to any other zone) so “as of when” is unambiguous when the user re-reads it later.

4. Run a UMS review, then close with the right signal

Run the full ums procedure (invoke the ums skill by name): scan the session for mistakes-corrected, new user preferences, tool quirks, and skill gaps — including whether spot-skill-opportunities flagged a recurring pattern during the session that’s still unbuilt; update the relevant memory files and skill definitions; commit via a branch + PR (not direct to main). If nothing durable emerged, say so explicitly rather than manufacturing edits.

Then close the reply correctly, depending on whether anything is waiting on the user:

  • Nothing open — end with an explicit stopping-point signal, e.g. “This session is at a good stopping point.” A silent trailing summary leaves the user unsure whether you’re actually done or just paused.
  • Something open — an ambiguous review item, a deadlock needing a human reviewer, a choice only the user can make — do not claim a stopping point. End the reply with the open question(s), last and clearly visible, rather than burying them earlier in a long recap. The last thing the user reads should be the thing you need from them.

Relationship to other skills

  • record-learnings (continuous) and ums (the learnings checkpoint, which this embeds as step 4) — wrap-up is their session-level bookend.
  • spot-skill-opportunities — step 4’s UMS pass checks whether it flagged a recurring pattern during the session that’s still unbuilt.
  • checkpoint / compress-session — narrower-scoped snapshots taken during a session (a task-phase snapshot, a pre-compaction distillation); wrap-up is the full session-level close-out these feed into, not a replacement for them.

Notes

  • Wrap-up reports PR/issue state and, where needed, resolves merge conflicts in unclaimed conflicting PRs (step 1). It does not merge PRs — merging stays the user’s call unless they ask.
Back to top