cleanup

Clean up after a merged pull request

Announce at start: "Using csw:cleanup to close out ."

Once the merge is confirmed, branch and worktree cleanup happens without asking. Closing a ticket always asks. Those two rules are not symmetric and the asymmetry is deliberate. Confirming the merge is itself the one precondition cleanup checks before it removes anything — that check is not optional, even though most of the time it passes instantly.

Step 1: Confirm the merge, then note where you are

Before anything is removed, establish that the PR for this branch is actually merged:

gh pr view --json state,mergedAt

If this run was chained straight from csw:merge, the merge is already confirmed there — say so, and this check simply passes; the chained path stays frictionless.

The only thing that authorises deletion is gh pr view reporting state: MERGED. Anything else is a stop-and-ask: a non-merged state, no PR for this branch, or the command failing for any reason — no auth, no configured remote, a network error, or anything else. Command failure is not "no signal, treat it as merged" — it is exactly the same stop as an explicit non-merged state. No substitute may be used to establish the merge instead: not git log --merges, not git branch --merged, not reading the PR page. Only gh pr view reporting state: MERGED counts.

If the check does not clear, stop. Name the branch and what you found — including the raw error if the command itself failed — and ask whether to clean up anyway. This is the one case where branch and worktree cleanup asks: git branch -d refuses an unmerged branch on its own, but nothing stops git worktree remove from deleting the checkout that holds someone's unlanded work, and the worktree carries no such protection of its own.

Once the merge is confirmed:

git rev-parse --show-toplevel     # this worktree's path
git branch --show-current         # the branch about to be deleted
csw-config get baseBranch