release-pr-review

When to use

git-wrapup has halted at an open release PR (gated mode) and the caller wants the release reviewed before it ships. The PR is the review target: the stack is committed, the tree is clean, gates were green when the PR opened.

Not for: PRs from outside contributors (those get a human reply, not a commit on their branch), non-release branches, or a PR that has already merged.

Preconditions

• The repo is checked out on release/<version> with a clean working tree
• The PR is open, and its head SHA equals local HEAD
• No tag v<version> exists yet — tagging is release-and-publish's job, after this pass

Verify all three in step 1; halt on any mismatch. The one exception to a clean tree: uncommitted work the caller explicitly hands over to ship in this release. Verify it against its description, commit it first as ordinary commits on top of the stack (step 5's conventions), add it to the changelog entry, and review it with the rest of the range. Any other uncommitted change is a halt.

Steps

1. Orient

git branch --show-current                                   # release/<version>
git status --short                                          # empty
gh pr view --json number,state,title,body,headRefOid,baseRefName  # state OPEN, base main, headRefOid == git rev-parse HEAD
git log --oneline main..HEAD                                # the stack: work commits, release commit on top
git diff main...HEAD --stat

Read framework-skills/code-simplifier/SKILL.md in full. Read the changelog entry for this version (changelog/<major.minor>.x/<version>.md) — it is the claim the diff has to back.

2. Establish the review range

The range is main...HEAD — every commit in the PR. code-simplifier's Phase 1 looks at the uncommitted diff and, finding none, falls back to the last commit; override that here: the diff under review is git diff main...HEAD, and new files are the ones git diff main...HEAD --name-status marks A. Everything else in the simplifier procedure applies as written: read the full files, survey adjacent code, run the project gate once for a baseline. A red baseline is a finding to fix in this pass, not to note and move past. One cause is peculiar to a PR that sat open: a dependency the install age guard (minimumReleaseAge in bunfig.toml) held back at wrapup has crossed it, turning devcheck's outdated check red — take the bump as an ordinary chore(deps) commit in step 5, recorded in the changelog entry's ## Dependencies.