A review that is not a rubber stamp

The failure this is for

A rubber stamp is not laziness. It is what an agent produces when nothing in its context can disagree with the author of the patch. The diff says what the change is, the description says why, and if those are the only two inputs then the honest output really is "looks fine".

Every genuinely useful thing a reviewer says comes from somewhere outside the diff, and each one lives in a different system.

The failure	What it looks like	What answers it
The linked issue is not what this fixes	"Fixes #482" nobody opened	the issue text, next to the patch
The checks never ran, or ran red	approved on the shape of the code	check runs and job logs
The changed function has other callers	locally safe, breaks three files away	code search across the repository
Wrong API for the pinned version	idiomatic call to a changed signature	version-specific documentation
The bug it claims to fix is still firing	a fix with no evidence it fixes	live error data
All the facts, and still "LGTM"	reach that nothing directs	a procedure with a discard step

The pairing people leave out

Reaching for a GitHub server here is obvious. Reaching for an error monitor is not, because Sentry reads as a debugging tool rather than a review tool, and by the time you are reviewing you have presumably finished debugging.

That is backwards on the pull requests that matter most. A bug-fix pull request makes a claim about the world outside the repository, and it is the one claim in the whole review with a checkable answer sitting in a system somebody is already paying for. Is that issue still firing. Does the function in the diff appear anywhere in the trace. A review that skips this can only assess whether the fix is well written, which is a different question from whether it is a fix.

Why the procedure is last and not first

The other three items are reach. They let the agent go and find something that contradicts the author. None of them make it want to.

The skill is the half that decides what to do with a contradiction, and its useful move is the one that sounds least impressive: it sorts findings into high, medium and low, and then it throws the low ones away rather than posting them. That is the difference between a review somebody reads and a review somebody mutes. Reach without judgment produces a wall of nitpicks and misses the call site; judgment without reach produces a checklist applied to a patch, which is the rubber stamp again with more words.

What is not here

No second issue tracker. The GitHub server already reads issues, and a Linear or Jira server would be a second item doing the first item's job, which is the test every candidate here had to pass.

And no second review skill, which is worth dwelling on. This catalog holds 1,680 skills across 690 repositories whose own path names say they review code or review pull requests. That is the number the search box gives you, and it is not useful to anybody: nobody is going to read 1,680 procedures to find the one with a discard step in it.

Picking one is the entire job. This is the pick.

claude mcp add context7 -- npx -y @upstash/context7-mcp
claude mcp add sentry -- npx -y @sentry/mcp-server
npx -y skills add alibaba/open-code-review --skill open-code-review