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	not solved here — see below

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.

This is the reach half. The judgment half is not solved.

Everything above is reach. The three servers let the agent go and find something that contradicts the author. None of them make it want to, and none of them tell it what to do when it succeeds.

That second half is a real and separate problem, and it is the one that decides whether anybody reads the review. Reach without judgment produces a wall of nitpicks and misses the call site: eleven comments about naming, nothing about the third caller. Judgment without reach produces a checklist applied to a patch, which is the rubber stamp again with more words. The useful move is the one that sounds least impressive — sort the findings, then throw the low ones away instead of posting them.

This page used to name a skill for that. It does not any more, and the reason is at the bottom. What you are left with is the instruction, which you can put in a rule file today and which costs nothing:

Classify every finding high, medium or low. Post the high and medium ones. Discard the low ones without mentioning them. If the whole review is low, say "no findings" and stop.

That is not a stack item. It is four lines in AGENTS.md, and until somebody here has run a review skill end to end, four honest lines beat a fourth row.

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 review skill at all, 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, and this page had a pick until 2026-08-13. The next section is why it does not now.

What the search changed

Checked 2026-08-13.

The fourth item was alibaba/open-code-review, specifically its skills/open-code-review directory. It was the judgment half described above: classify high, medium, low, discard the low ones.

Every stack in this directory then went through one grounded question: does any public source describe somebody running this combination, rather than these tools individually. This page got the strongest answer in the set for its first three items and a clear negative for its fourth.

The three servers, named together, five separate times:

• a developer MCP stack write-up listing GitHub, Sentry and Context7 in one table;
• a published stack configuration with github-mcp, sentry-mcp and context7-mcp in the same config block;
• an AI-code-review scenario guide arguing the 2026 setup is staged — GitHub MCP for pull request context, Sentry MCP for production error correlation, static analysis, then a human gate;
• pairing guidance describing exactly the Sentry-trace-to-GitHub-to-PR flow this page's first and third steps assume;
• a recommended developer stack listing all three by role.

Note what the third one is. It is an independent source arriving at this page's central argument — that production error data belongs in code review, not just in debugging — without having read this page. That is the strongest single piece of evidence behind any stack here.

Now the fourth item. Nothing found names it alongside the three servers. Worse, its own SKILL.md describes something narrower than this page claimed for it: it performs review via the ocr CLI on git changes. It does not document orchestrating a host agent's GitHub, Context7 or Sentry calls, which is the cross-check procedure the note above said it supplied. The search reported it as maintained, and as unclear whether it still fits the role given to it here. That is a claim we made about somebody else's software, and it did not hold up.

So the item is gone and the gap is stated instead of filled.

One thing worth knowing before you build this by hand. Managed reviewers are moving into exactly this space: Cursor Bugbot now attaches MCP servers for extra context on Team and Enterprise plans, Macroscope pulls Sentry signals natively and ranks findings by blast radius, and CodeRabbit takes user-configured MCP integrations. If your organisation already pays for one of those, the assembly on this page may be work you do not need to do. The argument for doing it yourself is the usual one: you can see what it checked.

claude mcp add context7 -- npx -y @upstash/context7-mcp
claude mcp add sentry -- npx -y @sentry/mcp-server