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.