pr-review-merge

PR Review-to-Green + Smart Merge

Source-agnostic. Consumers pass: PR number, base branch, and bot-reviewer/CI rules from the project's ## Marathon Configuration (defaults if absent).

Run-completion is gated elsewhere (floor)

This skill takes one PR to merge — a process signal. A green, merged PR is not proof the run's assembled product works, and this skill never certifies run-completion. That is gated by the acceptance-contract scripts the marathon engine invokes, not here: scripts/contract/start_gate.py fails closed at run start unless the contract is frozen before decomposition, scripts/contract/spawn_verifier.py is the sole custody chokepoint that spawns the cold non-implementing verifier against the assembled product, and scripts/contract/complete_gate.py fails closed unless that verifier's completion record validates. Merging here never substitutes for those gates. This note is part of the constitutional floor (FLOOR.md); the retro may propose changes but never self-apply them.

Ready Criteria (ALL must be true)

The PR is merge-ready only when all six are simultaneously true. Re-check from the top after every push — a fix can reopen an earlier criterion.

1. Branch in sync — no merge conflicts with base branch
2. CI passing — all checks succeed (or skipped)
3. All inline comments addressed — see thread resolution rules
4. No unaddressed conversation comments — actionable feedback responded to
5. All review threads resolved — no unresolved threads remain
6. Re-reviewing bots have reviewed the head SHA - every bot the project's Marathon Configuration flags Re-reviews on push: yes has completed its pass on the current head SHA. For a bot without Re-review check name, at least one of its reviews must carry that head SHA as its commit_id (a review of an earlier commit does not count), and that is the limit of this path: any review on the head SHA satisfies it, a placeholder or rate-limited one included, so a bot whose pass must be proven belongs on Re-review check name. For a bot configured with Re-review check name, only the check run of that name on the head SHA decides (its submitted reviews do not: the check run is what turns red when the reviewer exits with an error after posting), and that run has four observable states: in progress (or not yet created) - keep waiting until the max wait expires; completed with conclusion success - the criterion is satisfied for that bot, and the marathon skill's Commit:-line spot check still applies before merging on it; completed with conclusion skipped - the bot is not applicable to this PR (a reviewer job that skips some actors, such as Dependabot, by design), so the criterion is satisfied for that bot with no warning; completed with any other conclusion (failure, cancelled, neutral, timed_out) - a settled verdict that the bot did not complete a green pass, so the criterion takes the warning path at once. Any push restarts the wait. The wait is bounded per bot by that bot's Max wait for re-review, measured from when the head commit was pushed (the earliest check-suite creation on the head SHA, not the commit's committer date, which predates the push and resets on rebase); when Re-reviews on push: yes and Max wait for re-review is absent, the bound is 15m. If no check suite exists on the head SHA, fall back to the head commit's committer date as a floor - explicitly not the push time, it only guarantees the bound always expires. When the max wait expires before the bot completes, or a check-name bot's run settles on a conclusion other than success or skipped, the criterion passes with a warning recorded in the merge record (the PR comment or report that accompanies the merge) naming the bot, the head SHA, and what was observed: for a check-name bot, the check run's conclusion on that SHA (or that no completed run exists) and, so the record never contradicts the reviews endpoint, whether path (a) shows a review of that head SHA anyway; for a review bot, that no review of that SHA was found. The record states that the bot did not complete a green pass, not that it did not review. Merge proceeds with that warning; nothing holds forever on an advisory bot. Bots without Re-reviews on push: yes are never waited on, so a project with no such flags sees no change.