Merged — post-merge cleanup, checks, and (optional) release

The human just merged a PR. Run the tail of the pipeline they otherwise type by hand.

Arguments

• Optional PR URL/number (else detect: gh pr list --state merged or the current branch's PR).
• release — also cut a release after cleanup. Never release unless this word (or an explicit ask) is present — in some repos publishing a release deploys to production.
• keep — keep the PR's worktree and local branch. Without this word (or an explicit "keep the worktree"), removing them is the default.

Steps

1. Verify repo and merge. Resolve local nameWithOwner, then run gh pr view <pr> --json state,mergedAt,mergeCommit,headRefName,headRefOid,url. Require the PR URL repository to match the local repo and state to be MERGED. Otherwise stop before migration, deploy, release, or local actions.
2. Migration check (do not skip). Did the merged diff add DB migration files (gh pr diff <pr> --name-only against the repo's migrations dir)? If yes: verify the migration actually ran where the code deploys (deploy workflow run / migrator job logs) and say so explicitly. A shipped PR whose migration silently didn't run is a production incident — this check exists because it happened.
3. Answer the deploy question preemptively. From .github/workflows, state what this merge triggers on its own (e.g. "staging auto-deploys on merge to the default branch; prod only on a published release") and link the running workflow if one started.
4. Local cleanup, limited to this PR.
   • Resolve the default branch and locate its worktree plus the PR branch worktree with git worktree list --porcelain. Before switching or removing anything, run git status --porcelain in every involved worktree and stop if any is dirty.
   • Require the local PR branch tip to equal the recorded headRefOid; otherwise skip deletion and report unpublished or post-merge commits.
   • Update the default branch in its existing worktree with git pull --ff-only, or check it out in the primary worktree when free, then git fetch --prune. Never remove the primary worktree. If the PR branch occupies the primary worktree while the default branch is checked out elsewhere, leave the branch/worktree and report why cleanup was skipped.
   • Unless keep was given, remove the PR's linked worktree without asking: a clean tree at the verified head is all the permission needed. If this session's working directory is inside that worktree, run every other step first (release included) and do the removal, branch deletion, and prune last. Run the removal and every git command after it from the primary worktree (git -C '<primary-worktree>' …, or cd '<primary-worktree>' && in the same Bash call), because git cannot run from a deleted directory.
   • Pick the removal command by whether Orca manages the worktree, not by which terminal is running. If command -v orca succeeds and orca worktree list --json contains a "path" equal to the worktree path, run orca worktree rm --worktree "path:<worktree-path>". If that command fails, stop and report the exact cleanup the user still needs to do; do not fall back to git. If orca exists but the list call fails, ownership is unknown: skip the removal and report it (for example, "open Orca and rerun, or remove it yourself"). Only with no orca, or a successful list that does not contain the path, run git worktree remove <worktree-path>.
   • Then delete the local branch if it still exists (Orca may already have deleted it). Try git branch -d first. After a squash/rebase merge, allow git branch -D only because the PR is verified merged and the local tip exactly matches its recorded head. Never remove unrelated branches or worktrees.
   • Run git worktree prune to clear stale administrative records. Do not delete untracked files or vaguely named "planning artifacts"; each workflow owns and removes its own temporary files.
5. Release (only if requested). Prefer a repo-local release skill or command (for example .claude/skills/release/ or .claude/commands/release.md); otherwise use the repo's documented release process.
6. Report. One compact block: merged PR, migration verdict (none / ran / NOT VERIFIED — flag loudly), what auto-deploys, branches/worktrees removed (and whether through Orca or git) or kept, release link if cut.

Red flags

• Any temptation to gh pr merge → never; this is a verify-only skill.
• Migration present but you can't confirm it ran → make it the FIRST line of the report and suggest how to verify; never bury it.
• The default branch is checked out in another worktree → run the update there; do not remove or force it.