Skip to content

v2.4.0

Choose a tag to compare

@n-shadloo n-shadloo released this 14 Aug 09:46
· 8 commits to main since this release
v2.4.0
394ca6b

v2.4.0

Minor release. Adds a sixth mode: the skill now reviews an incoming pull request on the
maintainer's behalf. MINOR rather than PATCH because the new mode is new functionality.
Every request that worked in 2.3.1 behaves identically here — the five existing modes are
untouched — and the read-only guarantee that covered modes 1–3 and 5 now covers mode 6 too.

A mode for the receiving end

The five existing modes all serve the author of a change. Mode 6 serves the person on
the other side of the table: the maintainer deciding what to do with someone else's branch.
It runs only when asked — "review PR 412", "should I merge this", "look at this PR with
me" — and never fires as part of a commit or PR-authoring request.

It gathers the pull request read-only through gh: the diff, the CI checks, the existing
review threads, the linked issue, the commits and their authors, and the repository's merge
method. CONTRIBUTING.md is read when the project has one, and the existing review threads
are read before an opinion is formed, so a point someone already raised — or the contributor
already answered — isn't repeated back.

Empty gh pr checks output on a fork PR means "not run," not "passing." Workflows on a
cross-repository PR frequently need maintainer approval before they execute at all, so
silence there is reported as silence. A check is never asserted to have passed that wasn't
seen passing.

Blocking versus suggestion, calibrated to the project

Two buckets, and only two. Something blocks the merge only if merging leaves the project
worse off than not merging: it breaks the build or an existing test, loses or corrupts data,
opens a security hole, breaks a documented contract without notating it, or does not do what
the PR claims. Everything else — naming, structure, a nicer abstraction, broader tests — is
a suggestion, and a suggestion is never on its own a reason to withhold a merge.

The bar moves with the project. Applying a large project's standards to a small one is
the most common way this kind of review goes wrong. Where there is no stated convention, no
CI gate, and few contributors, most findings are suggestions the maintainer is free to take
or leave: missing tests in a repo with no test suite is not a blocker, and neither is
ignoring a rule the project never wrote down.

Two rules hold at any size. A blocker is never manufactured to make a review look
thorough — that produces exactly the reviews that make contributors stop contributing. And
the verdict leads: when nothing blocks, that is the first line, not the conclusion of
six paragraphs of observation.

It decides with you, and writes one block

The findings are talked through before anything is drafted — what the PR does, what blocks
it if anything, what is merely suggested — and then the maintainer decides. Taste is labelled
as taste. Merging over a raised finding is a legitimate call, noted once if genuinely risky
and not relitigated.

Then exactly one Markdown block is produced, for the decision actually made: either a
review comment (verdict first, blocking items separated from optional ones, pointing at
code and locations rather than at the contributor) or the merge-commit message. Not
both, and not preemptively.

The squash-merge message

On a squash merge GitHub prefills the subject from the PR title and the body from every
branch commit concatenated together. That default is usually noise, and it is the commit
that lands on the default branch and stays in git log forever — the most consequential
message in the PR lifecycle, and by default nobody writes it. Mode 6 writes it fresh from
the diff with the ordinary commit discipline; the contributor's subjects (wip, fix stuff) are a hint at intent, not source text to tidy. A merge commit keeps GitHub's
default, and a rebase merge has no new message to write, which is said rather than papered
over with one.

Co-authored-by: is transcribed here — the one exception to the no-attribution default.
A squash collapses every commit on the branch into one and credits only the PR author, so
when the branch has more than one commit author each is carried across as a
Co-authored-by: trailer copied exactly from the real commit metadata. This is the single
place the skill emits an attribution trailer without being asked, and it is still not
inference: it preserves authorship that already exists rather than asserting anything new.
The 2.2.0 default is otherwise untouched — no agent identity, no Signed-off-by:, and never
a name or address that didn't come from a real commit or from you.

It never touches the button

Mode 6 is read-only, and mode 4 does not extend to it. gh pr review, gh pr comment,
gh pr merge, gh pr close, gh pr edit, and any gh api call with a method other than
GET are never run. "Approve it", "go ahead", and "yes, merge" tell the skill what the block
should say — they are never permission to carry it out, and no autonomous request reaches
here. Mode 4 stages, commits, and pushes your work; it never lands someone else's.

Files updated

  • SKILL.md — version bump to 2.4.0; mode 6 added to the mode contract, the ground rules,
    and the reference list; a mode 6 section with the gathering commands and the merge-message
    rules; the trailer section gains the squash-merge exception. The frontmatter description
    was recompressed to hold under the 1024-character limit — the mode enumeration gave up the
    room, and every trigger phrase is intact.
  • references/pr-review.md — new. Gathering the PR read-only, the fork-CI caveat, the
    blocking-versus-suggestion test and how to calibrate it to project size, working the
    decision through with the maintainer, the review comment, the merge-commit message with
    co-author transcription, a worked example, and the hard limits.
  • AGENTS.md — mode 6 and the mode 4 boundary, written self-contained.
  • README.md — six modes throughout; mode 6 documented in the Use section; the attribution
    section gains the one exception; layout tree updated.
  • GEMINI.md, .cursor/rules/git-authoring.mdc — mode contract, review rules, and the
    mode 4 boundary updated; both still defer to AGENTS.md for detail.

Upgrade notes

Drop-in replacement for 2.3.1. The five existing modes are unchanged, and the no-attribution
default from 2.2.0 still governs every one of them. Two things worth knowing: the read-only
guarantee now reads "modes 1–3, 5, and 6", and gh — optional for modes 1–5 — is required
for mode 6, since reading the pull request is the whole input. Mode 6 still only reads: it
writes Markdown for you to paste.

Full Changelog: v2.3.1...v2.4.0