post-merge

Post-Merge

Local cleanup after a PR is merged. One run takes a merged PR from leftover-review surface → branch cleanup → issue close → repo About check → commit. It records no lessons: those go to /retro in the session that built the change. Follow project guidelines in @CLAUDE.md and @AGENTS.md throughout.

Guidelines

• Worktree mode. post-merge runs from the main repo or from the PR's worktree. Every step works on the main repo: git calls run as git -C "$MAIN_REPO" and repo paths resolve under $MAIN_REPO/, in the steps below and in references/. MAIN_REPO=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)") gives the same answer from either place, so re-derive it in any fresh shell. Inside a worktree (IN_WT=1) Step 1 copies the worktree's review-loop state into the main repo's archive, Step 4 leaves the branch alone (the worktree still has it checked out), and Step 11 prints the one command that removes the worktree and the branch. post-merge never removes the worktree itself: on Windows a worktree removed from inside itself is only half deleted.
• Non-default base. For a PR into a branch CodeRabbit does not auto-review, review-loop on the auto / pr-bot source posts @coderabbitai review itself, unless the repo set reviews.auto_review.enabled: false (plugins/dev/skills/review-loop/SKILL.md Step 2); Step 3 below checks out that base like any other. It also changes what the merge did to the linked issues: GitHub honours a closing keyword only on a merge into the default branch, so a non-default base leaves every one of them open with no signal on the PR page — Step 5 is what catches that, and it runs on every PR.
• gh is the authoritative merge signal. Step 1's gh pr view ... state=MERGED is the single source of truth for "did this land", and Step 3.5 asks gh the same question (gh pr list --head <branch>) for every other worktree's branch. No step decides "merged" by comparing git SHAs.
• SHA comparison proves "nothing unique", never "merged". git log <base>..<branch>, git cherry and git rev-list --left-right read as unmerged after a squash merge (base gets one new SHA) or a rebase merge (branch SHAs rewritten), so none of them answers "did it land". Step 3.5 runs git cherry only after gh has said merged, to show the branch holds no commit the PR did not deliver, and settles whatever cherry still lists by content: the branch's files against the PR's merge commit. If unsure content landed, diff content, not SHAs (Step 4).
• Leftover-review surface (Step 1.5) is informational. The run reads review-loop's state file (.claude/state/review-loop-<PR>.json, else the latest .claude/state/archive/ copy, else the same under the pre-rename cr-fix- prefix) to surface autonomously-deferred or cap/timeout-stopped findings after the merge, but never blocks cleanup. It always prints one leftover-reviews: … checkpoint line so a skip can't pass unnoticed. gh / jq / Read only → identical under Claude and Codex.
• Codex partial-execution. /docs:readme and /docs:changelog (Steps 9, 9.5) are commands, which Codex does not load; under Codex do the same edit by hand from the docs:doc-guides skill and note it. Every other step runs identically on both runtimes.
• Interactive input is capability-aware. Every prompt and confirmation below, each AskUserQuestion mention included, is a gate rather than a tool name: AskUserQuestion under Claude Code, request_user_input under Codex where exposed, otherwise one concise blocking question asked before the irreversible action (git rm, git worktree remove, git push origin --delete, gh repo edit). Full policy: AGENTS.md → "Cross-runtime interactive input policy".
• Run record. Step 1 opens .claude/state/post-merge-<PR>.json and every step appends its outcome, so a silent skip becomes visible; Step 10 finalizes it. Mechanism, per-step skip reasons, and the finalize block: references/run-record.md.