Open-PR: an AI agent that reviews PRs like a colleague, not a bot

AI coding helps write code faster, but the number of open PRs has grown too, while the number of reviewers hasn't. The result: review not writing code is the new bottleneck.

Open-PR was born from that an open-source AI agent dedicated to reviewing Pull Requests, running directly inside familiar agent CLIs (Claude Code, Cursor, Codex, Gemini CLI, Antigravity) instead of as a SaaS service or a separate bot account:

Developer opens a PR → AI does the first review pass → the human reviewer makes the final call → merge.

There are already quite a few AI agents doing code review. So what makes Open-PR different?

Not just a "generic review prompt"

Many review skills/agents today are just a description file (SKILL.md) telling the AI to "review carefully." The problem is that each run behaves differently sometimes strict, sometimes lenient and it knows almost nothing about the project's own conventions.

Open-PR is different: the very first time it runs in a repo, it reads the README, CLAUDE.md, AGENTS.md, docs, and wiki to understand that project's actual conventions, and the team's own rules always win over generic ones. It also has memory per repo: everything the team has ever pointed out or agreed on gets recorded, so the next review doesn't need to repeat it. Thanks to that, no matter when it runs, the review keeps the same "voice" the project's own voice, not one that drifts from run to run.

A friendly, detailed back-and-forth like two people discussing code

The most notable thing about Open-PR isn't how many bugs it finds, but how it keeps the conversation going on the PR.

An "old-style" AI review usually dumps a pile of comments and stops there; running it again means reviewing from scratch, sometimes repeating exactly what it already said. Open-PR is different: run /open-pr:review a second time on the same PR, and it re-reads every existing thread to check whether each point raised has been addressed — if it's been fixed, it confirms right on that same thread (and can auto-resolve if you enable that option); if not, it stays quiet instead of repeating the old finding. The new review only talks about what just changed.

Even more interesting is /open-pr:fix. Instead of blindly applying whatever a comment says even when the comment is wrong and would turn correct code into broken code Open-PR weighs whether the finding actually makes sense. If it's valid, it fixes it according to the repo's conventions and memory; if it isn't, it replies right on that thread with evidence, like a developer pushing back on a reviewer rather than obediently following orders. After pushing, it always goes back to every thread to explain exactly how it was fixed or why it wasn't and it never resolves threads itself; the right to close a thread always belongs to a human. That keeps the conversation anchored exactly where the issue was raised, instead of "restarting" every time it runs.

Comments aren't just for flagging bugs they explain clearly, with evidence

Each review pass has three tightly linked parts:

• Overview (the whole diff at a glance, findings grouped by severity, including file-level issues with no specific line to attach to).
• Line comments (findings attached to the exact relevant line, each with a ready-made suggestion block so it can be committed directly from the PR interface, no retyping needed).
• Replies (after /open-pr:fix pushes, it replies right on that thread to close the loop).

To make sure the AI and humans understand each other clearly, Open-PR uses an explicit severity system like a "contract" between reviewer and author:

Symbol	Severity	How /open-pr:fix handles it
🔴	MUST FIX	handled automatically
🟠	SHOULD FIX	handled automatically
🔵	SUGGESTION	always asks before touching code
📝	NOTE	always asks before touching code

If the diff has nothing worth flagging, it just posts a single line: LGTM 🌟 — no noise. Six categories of criteria are considered: bugs & logic, security, performance, code quality, maintainability/readability, and framework/language-specific rules (Rails, Vue, React, Python, Node.js, Laravel, WordPress, etc.) the team's own rules always win in case of conflict.

Choosing the default language for PR comments

Open-PR separates two languages: the language you chat with the agent in inside the CLI (chat_language), and the language it posts publicly on the PR (output_language) this setting is tied to each repo, not to each user.

The first time it runs in a repo, Open-PR asks a short round of questions to pick the language for posting on PRs, then remembers it for every run after that. That way, a repo can always review consistently in Vietnamese (or English, Japanese, Chinese), no matter who on the team runs the review command.

Setup with Claude Code

First, make sure you have the GitHub CLI installed and logged in:

gh auth login

Add the marketplace and install the plugin:

/plugin marketplace add TOMOSIA-VIETNAM/open-pr
/plugin install open-pr@open-pr

Then run a review directly on a PR:

/open-pr:review <PR_URL>

Example:

/open-pr:review https://github.com/your-org/your-repo/pull/123

Claude Code will analyze the PR and return findings for you to review before merging. When you're ready to apply the parts you agree with, run /open-pr:fix <PR_URL> a single commit, no force-push, always replying on every thread after pushing.

Comments

[Riven Desk]

The thread-aware re-review is the interesting part here. A second pass that checks what changed since the last review—and stays quiet on already-addressed findings—sounds much more useful than another full dump of comments. I also like the explicit human ownership of resolving threads. One question I’d test in practice: how do you distinguish “finding fixed” from “the diff’s scope changed enough that the original review is stale”? That intent/scope check seems like the boundary between a helpful reviewer and a very confident checklist runner.

[Open PR]

Fair question to raise.

Open-PR doesn't decide by checking whether a line of code still exists. On a re-review it reads the code around the comment, works out what the comment was asking for in the first place, and then decides whether that ask has been met. Code that has shifted enough that the old comment no longer clearly applies gets handled as its own case, separate from "same issue, now fixed."

We aren't claiming the AI gets every call right. The clear-cut ones it does fine with: a fix is a fix, and a bug nobody touched is still a bug. Where it shouldn't be deciding alone is the murky end, such as a large refactor that moves the scope out from under the original comment. So when the model isn't sure, Open-PR errs on the side of leaving the thread open instead of assuming it got resolved. Closing a thread stays a human decision either way, never an automatic one. The AI is there to help with review, not to take over the hard judgment calls.

[Miu]

Managing PR reviews with a fast-moving dev team was killing my productivity. Most AI review tools I tried were pretty useless for us—way too verbose, or they needed CI pipeline access, which is a hard NO on client projects due to compliance.

Switched to Open PR and it actually solved the problem. Here is how we run it:

1. Devs run OpenPR on their branch first and fix issues until it looks good.
2. I run a second pass on my machine (takes a minute or two max).
3. I do the final human review.

Handling ~20 PRs a day is super smooth now. Big thanks to the team for building this! :)