tomosia-vietnam/open-pr

AI code review that lands directly on your PR. Open source. Self-hosted. Works with  GitHub ·  GitLab ·  Bitbucket /open-pr:review · /open-pr:fix

Tiếng Việt · English · 日本語 · 简体中文

AI coding made PRs faster. But review didn’t get faster.

open-pr runs that first review round for you — on the PR, not on your laptop. Anyone who opens the PR sees the same feedback.

One run produces three parts that belong together: an overview, line comments (with suggested changes), and a reply after /open-pr:fix has pushed. — See the demo

• Exactly 1 review per run — one review posted, not a stream of bot comments
• Learns your repo — README / CLAUDE.md / AGENTS.md / docs / wiki; team rules beat generic rules
• Remembers what the team said — a correction on one PR carries into the next run
• /open-pr:fix is disciplined — exactly 1 commit, no force-push, a reply on every thread
• Open source, no open-pr service — MIT-licensed, no open-pr server or bot account; it runs in the agent CLI you already have

Listed in Awesome AI Plugins, which gates the listing on its own scan of this repository — score ≥ 80, no high or critical finding. A scan is a trust signal, not a safety guarantee.

Install

1. A vendor CLI, logged in. The plugin carries no credential of its own — it reads the PR and posts the review through your account:

# GitHub
brew install gh          # or https://cli.github.com/
gh auth login            # GitHub.com → HTTPS → Login with a web browser
gh auth status           # must say "Logged in to github.com as "

GitLab: brew install glab && glab auth login --hostname gitlab.com. Bitbucket ships no CLI — it reads BITBUCKET_EMAIL + BITBUCKET_API_TOKEN from the environment. Minimum permissions and how to check them: Getting a token per vendor.

2. The plugin. Claude Code:

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

Install for Cursor, Codex, Gemini CLI, Antigravity:

curl -fsSL https://raw.githubusercontent.com/TOMOSIA-VIETNAM/open-pr/main/install.sh | bash

Full guide: Install · Getting a token per vendor.

PR URL formats: GitHub .../pull/ · GitLab .../-/merge_requests/ (self-hosted included) · Bitbucket Cloud .../pull-requests/.

Why review is the bottleneck

In the age of AI coding, PRs ship far faster than they get reviewed. The bottleneck is no longer coding — it’s review. Reviewers have to check the project’s conventions / security / performance and cover business logic — and that doesn’t scale well as PR volume grows.

A local review is hard to trust. Anyone can say “I already reviewed it”. So open-pr moves that step to remote for transparency — comments sit on the PR, and anyone who opens it can see them.

[!NOTE] Review rounds (a suggestion for the team):

1. Round 1 — Dev runs AI review on the PR themselves. No review comments yet → reviewer sends it back, without touching it.
2. Round 2 — Reviewer runs it again (AI). Clean → LGTM.
3. Round 3 — Reviewer reviews the domain part.

[!IMPORTANT] AI lightens the process load, but final responsibility is still yours.

How it differs from a generic review skill

Many review skills are just a SKILL.md description. Each run comes out differently — different wording, different strictness, easy to drift from the project’s conventions.

[!TIP] The part worth keeping: no matter when you run it, the procedure is the same — bootstrap conventions, pick the output language from the repo, then remember what the team has reminded. Not one AI voice today and another tomorrow.

Review flow

flowchart LR
  A[New PR] --> B["Round 1 · /open-pr:review"]
  B --> C{Review on remote?}
  C -- not yet --> D[Reviewer sends it back]
  C -- yes --> E[Dev fix / /open-pr:fix]
  E --> F["Round 2 · review again"]
  F --> G{Clean?}
  G -- yes --> H[LGTM]
  G -- not yet --> E
  H --> I[Round 3 · human domain review]

Details on re-review, worktrees, and the guard before fix: Re-review / fix flow.

Commands

[!WARNING] fix edits real code in the repo (or the review worktree). Run it only when you deliberately want it to handle the comments.

Full configuration: Configuration.

What it reviews

1. Bugs & logic
2. Security
3. Performance
4. Code quality
5. Maintainability & readability
6. Framework / language-specific — from that stack’s template

Criteria in detail and priority when they conflict: What it reviews.

Prompt token chart

Mean tokens per run — covering both happy-case and bad-case:

---

Contributing? CONTRIBUTING.md.

Enjoy reviewing 🥰

Logo files: docs/logo.md