ThinkReview vs local Claude /code-review: the pull request needs different eyes

ThinkReview vs local Claude /code-review: the pull request needs different eyes

The session that wrote the branch is a weak place to decide whether the branch should merge.

Claude Code is a strong way to write a change. After it writes one, the local command is /code-review. You type it in the session you are already in. Claude reviews the branch, looks for correctness bugs, and reports them in that same conversation. With --fix, it applies the findings to the working tree.

That is a useful pass while you are still editing. It is a weak last pass before merge. The tool that typed the code is the tool asked to bless it. ThinkReview starts from a different object and a different reviewer: the pull request, read by a review that never sat in the authoring session.

What local /code-review actually reviews

Anthropic’s docs are precise about the default. With no target, /code-review reviews your branch’s commits ahead of upstream plus your uncommitted changes. If the branch has no upstream, Claude compares against main, or against the previous commit. The review runs in your own session, on your plan’s usage, and it follows your CLAUDE.md.

A few details matter if you are treating that command as the merge review:

• It runs as a background subagent with its own context window, so the findings do not have to share the full transcript. A new window is a new conversation. It is still Claude Code, still the product that wrote the change, still bound to the instructions that shaped the implementation.
• --fix writes the findings back into that working tree. The author reviews the author, then edits the result.
• You can point the command at a pull request number, a path, or a commit range. The command people run when the chat says “done” is the one with no arguments. That one includes files that are not on a pull request yet.
• --comment can post findings to a GitHub pull request or a GitLab merge request. The review that produced them was still generated inside the Claude Code session.

Claude also offers a separate managed Code Review service that an Owner turns on for GitHub. That product comments on pull requests for Team and Enterprise. This post is about the local command, the one in the session that wrote the code.

A pull request is the thing that merges

ThinkReview reviews the pull request or merge request URL. On ThinkReview MCP, the assistant calls review_url_code with that link. ThinkReview fetches the diff through the git credentials in the portal and returns the same structured review as the browser extension: summary, severity, security notes, and the reason in plain language.

The object under review is the change GitHub, GitLab, Azure DevOps, or Bitbucket will merge. Uncommitted files still sitting in the editor stay out of that review until they are on the pull request. Dirty work can be interesting while you edit. It is invisible to the person who clicks merge. A review of the URL is a review of the proposal.

Local /code-review can see work that has never been pushed. That is handy at 1 a.m. It is the wrong boundary for a ship decision. The boundary is the diff on the host.

A different set of eyes

The session that wrote the code has a story about why the code looks like that. The cancel handler returns HTTP 200 because that made the trial screen succeed. The eligibility check lives on the client because that was the shortest path to a working demo. A reviewer who shares the author’s tool, the author’s CLAUDE.md, and the author’s plan is under pressure to stay consistent with that story.

A fresh subagent reduces how much of the transcript it sees. It does not give you a second opinion from outside the tool. The second opinion is a different product, often a different model, looking only at what the pull request contains.

ThinkReview is that review. You choose the model in Model selection, so the reviewer can be a different family from the model that opened the branch. It does not continue the Claude Code conversation. It reads the diff and reports findings a founder can hand back to whatever agent wrote the branch: Cursor, Copilot, or Claude Code itself.

That split is what catches the bug the authoring session explains away. “Cancel returns 200 on failure” is coherent inside the session that wrote it. On the pull request, read by a model that did not type it, it is a critical finding: the billing provider will not retry a success, and the trial can stay live on their side while your app says it ended.

Use Claude to build. Review the pull request apart from it.

Keep local /code-review for the editing pass. It can see uncommitted work, and --fix can clean that work up before you open anything.

Use ThinkReview when the question changes from “is this branch tidy?” to “should this merge?”

1. Let Claude Code, Cursor, or Copilot write the branch.
2. Open the pull request so the change has a URL and a diff.
3. Run ThinkReview on that URL, from the extension or from MCP, on a model you picked for review.
4. Fix the findings that would hurt in production, then merge.

If you want that loop in one Cursor invocation, /thinkreview-pr resolves the pull request, calls ThinkReview MCP, patches the critical and high findings that deserve a change, tests, pushes to the same pull request, and reviews again. The write-up of that call is code reviews for vibe coders.

The local command and the pull-request review can both exist. They answer different questions. Only one of them is a different set of eyes on the thing you are about to ship.

/code-review behavior is from Anthropic’s Review locally with /code-review. The managed GitHub service is a separate product, documented at Code Review. ThinkReview reviews the pull request from the extension or from MCP.