skills: reviewing-pull-requests can post its own review and trigger CI (v1.8.0)

[oksuzian]

Lets reviewing-pull-requests finish the job — post the review to the PR — instead of stopping at a staged draft that needs a second command. Opt-in, off by default.

Why opt-in

Publishing writes to a colleague's PR under the invoking user's name. That is not something a skill update should switch on for someone, so nothing changes for anyone who does not ask for it: the skill drafts, reports the path, and /post-pr-review publishes, exactly as today.

Auto-post activates only when PR_REVIEW_AUTOPOST is set in the environment, or when the request itself says to post — an explicit "review and post", or a scheduled sweep whose prompt says so.

What is in it

• reviewing-pull-requests 1.6.1 → 1.7.0 — new "Publishing the Review" section: the opt-in check, four fail-closed gates (naming, staleness, decision mapping, duplicate), the gh pr review invocation, and a "When NOT to post" list. The body is posted verbatim and never rewritten at post time.
• post-pr-review 1.0.1 → 1.1.0 — cross-references the new section; still the normal publishing path for anyone who has not opted in.

The naming gate is worth a look even if you never enable auto-post

Draft filenames are now repo-qualified (<repo>_pr<N>_review.md) and the draft's first line must name Mu2e/<repo>#<N>. PR numbers collide across repos — Offline#7 and ArtAnalysis#7 both want pr7_review.md — and the naming gate is what stops a review landing on the wrong PR. This bit me in practice before the gate existed.

Validation

Exercised across four review rounds on Mu2e/EventNtuple#381 today (🔴 → 🔴 → 🟡 → 🟢) plus ArtAnalysis#7, Offline#1917/#1918/#1919, MLTrain#8 and an EventDisplay release tag. The gates fired as intended: the staleness gate caught a head that moved mid-review, and the "no PR to post to" case correctly left the EventDisplay tag review staged.

Not validated: the PR_REVIEW_AUTOPOST-unset path has not been run end to end, since my environment sets it.

---

Added: FNALbuild CI trigger (reviewing-pull-requests 1.7.0 → 1.8.0)

Second commit, same theme — which GitHub writes this skill is allowed to make. A review that turns on "does it build" is worthless without a build at the head being reviewed, so the skill may now ask for one:

gh pr comment <N> --repo Mu2e/<repo> --body "@FNALbuild run build test"

That is the only additional write authorized. It explicitly does not extend to gh pr edit, gh pr merge, gh pr close, git push, or any other comment.

Scoped to Offline and Production. FNALbuild watches neither of the other seven skill-scope repos — ~1580 comments on Offline and ~449 on Production, against zero on EventNtuple, EventDisplay, DQM, Tutorial, PassN, RefAna and ArtAnalysis. Posting the phrase elsewhere is a no-op comment on someone's PR, so the section says to check the repo first.

The guards matter more than the trigger, since build slots are shared collaboration-wide. Do not fire when a run is already queued at the current head, when the head is already green, or when the failure is genuinely caused by the diff — re-running reproduces it, so report the failing target as a finding instead. An invoking instruction that forbids state-changing commands (a scheduled sweep, a read-only brief) wins over the section; the review then records needs a CI run at <sha8> and leaves it to a human.

Validated by the guard firing correctly on Mu2e/Offline#1918: head had moved to faffc80f, but a build was already in flight there, so the correct action was to not trigger.

🤖 Generated with Claude Code