Ship It

Input: a PR number or URL, or nothing, then use the current branch's PR (gh pr view with no argument resolves it). If the current branch has no PR yet, push it and open one with gh pr create (maintainer branch only), then continue. Goal: the PR merged with every code-review finding fixed and CI green.

0b. A figure in the description, when the change has a shape

If the PR changes how something flows, a request path, a background job, what a feature does step by step, a picture explains it faster than the diff does. Use the figure skill: write a JSON spec, render one animated SVG, and put it at the top of the PR description. It plays in the description with no upload and no click.

Reference it by commit SHA, not branch name, or the image dies when the branch is deleted at merge: https://raw.githubusercontent.com/<owner>/<repo>/<sha>/<path>.svg. If the SVG is not part of the change itself, don't commit it to the repo, render it, commit it on the PR branch only if it belongs there, and otherwise keep the description's image pinned to the commit that carried it.

Skip it for a fix with no shape: a one-line guard, a dependency bump, a typo.

0. Blocker rule (applies at every step)

A blocker is a finding whose fix would go against the PR's goal, the code-review principles say the thing the PR sets out to do is wrong (e.g. the PR's whole point is a raw-SQL handler, a new advisory lock, a tuple-returning API, a test that asserts via SQL, dropping bank scoping), or fixing it would mean rewriting/removing the feature rather than polishing it.

On a blocker: stop immediately. Don't push, don't merge, don't partially fix. Tell the user what the PR is trying to do, which principle it conflicts with (quote the code-review section), and the options you see, then ask for confirmation with AskUserQuestion. Resume only on an explicit answer.

Everything else (must fix, should fix, nits) is not a blocker: fix it all.