fix(running-in-ci): batch pushes so the author doesn't cancel its own reviewer

[tend-agent]

Problem

tend-review triggers on pull_request_target: synchronize under a per-PR concurrency group at cancel-in-progress: true (review.yaml.j2). Every push to a bot-authored PR therefore starts a replacement review run and cancels the one already going. Nothing in the skills tells the author side to batch its pushes, so a session that opens a PR and then pushes a follow-up commit thirty seconds later spawns a reviewer purely to kill it.

On PRQL/prql in the 07:44Z–08:44Z window, 5 of the 8 tend-review runs on bot-authored PRs were cancelled, and 4 of those posted nothing at all. Each cancellation traces to the same bot pushing again while its own reviewer was running.

PR	head	review run	started	ended	lifetime	review posted
#6149	43b1738a	31082377982	07:49:05	cancelled 07:49:45	40s	no
#6150	1979e288	31084139419	08:15:14	cancelled 08:15:47	33s	no
#6150	ce92ec84	31084169295	08:15:39	cancelled 08:15:53	14s	no
#6150	270aa2b1	31085384920	08:33:29	cancelled 08:35:43	2m14s	no
#6147	94ceeca5	31081526145	07:35:42	cancelled 07:51:42	16m00s	no

The sharpest case is #6150. The session created the PR at 08:15:09, pushed ce92ec84 (chore: changelog entry) ~28s later, then force-pushed it as eaf11545 ~12s after that — gh api repos/PRQL/prql/compare/ce92ec84...88867eeb returns status: diverged, confirming the rewrite. Three review runs fired inside 42 seconds; two died before doing any work. The changelog entry had no reason not to be in the initial push.

The 16-minute loss on #6147 is the same rule from the other end: run 31081526145 had been reviewing for 16 minutes when the author session pushed 0efb4aea, and its analysis went with it.

Solution

A new Batch the push subsection under running-in-ci's "Pushing to PR Branches", stating the mechanism once and two rules: commit everything before gh pr create, and make the commits then push once rather than pushing after each. It notes explicitly that amends and rebases fire synchronize too, since the #6150 case went through a force-push. A closing line keeps the legitimate case intact — a push that acts on review feedback should invalidate the running review; the ask is to land it as one push, not several.

running-in-ci is the right home because every session that pushes reads it, and the sessions producing this were tend-mention handle legs rather than any one workflow's skill.

Relationship to existing work

This is the author-side counterpart to #830 / #834, not a duplicate. Those cover a review session cancelling itself by pushing a fix before submitting its review; the ordering rule there protects the pusher. Here the pusher is a different session entirely, and the victim is a reviewer that has no way to protect itself — so the rule has to live on the author side. The two compose: #834 makes the reviewer push last, this makes the author push once.

Gate assessment

• Evidence level: High — a consistent pattern across multiple independent sessions (the #6149 handle leg, the #6150 handle leg, and the #6147 author session), not a single lapse. High requires 2–3 occurrences; this window alone has 4 cancelled-with-nothing-posted runs, and the evidence gist carries one prior recorded occurrence (tend-nightly pushes to its own just-opened PR, cancelling that PR's first review mid-flight — recorded at cumulative 1 with "act at 3+"). Cumulative 5.
• Structural vs stochastic: structural in its consequence. Given two pushes within a minute, the first review run is cancelled every time — there is no decision point in the cancellation itself, only in whether the author batches. Replaying the scenario 10 times cancels 10 times.
• Change type: targeted fix — a missing step added to an existing section, no new section and no workflow change. Normal bar, met.
• Passes both gates: yes.

Testing

Skill prose, so no test to add. The structural claim was verified against the generator template rather than assumed: review.yaml.j2 shows types: [opened, synchronize, ready_for_review, reopened] with group: ${{ github.workflow }}-${{ github.event.pull_request.number }} and cancel-in-progress: true. Every run ID, head SHA, and timestamp in the table above comes from gh api repos/PRQL/prql/actions/runs/<id>; the review-posted column was checked against gh api repos/PRQL/prql/pulls/<n>/reviews. Checked the co-loaded skills before adding guidance — review/SKILL.md line 370 discusses cancelled check runs, not the review session, and no skill carried an author-side batching rule.

Evidence log: https://gist.github.com/192514ea2c36586f9b7f842a482d62ab

[tend-agent]

Mechanism checks out against the template — review.yaml.j2 has types: [opened, synchronize, ...] with a per-PR group at cancel-in-progress: true, so the causal chain in the body is right and the rule follows from it. Two wording points below.