Open Code Review: a multi-agent reviewer team for AI-assisted development

The single-perspective problem Open Code Review targets

Ask one AI assistant to review a diff and you get one set of priorities. The README frames this as the core motivation: "one pass, one set of priorities." Open Code Review, abbreviated OCR throughout the project, answers that with several reviewer instances examining the same code independently. The stated reasoning is that different attention patterns catch different issues, so what one reviewer misses another finds. The intended user is a developer already working with an AI coding assistant such as Claude Code, Cursor or Windsurf, who wants a structured review pass before a human opens the pull request. The README is explicit that this does not replace human review. Its stated goal is to reduce the burden on human reviewers by catching issues earlier, so human attention goes to things machines cannot catch. That framing matters when you decide where in your workflow to place it.

How the reviewer team, discourse and synthesis fit together

The README's diagram describes a pipeline with four stages. A Tech Lead orchestrates the review. Below it sit the reviewer instances, drawn from whatever team composition you configure. Those reviewers then enter a discourse stage, where according to the README they debate findings, challenge assumptions and validate concerns rather than simply emitting a list. A synthesis stage produces unified, prioritised feedback. Two inputs shape what the reviewers look at beyond the code itself. Requirements-aware review lets you pass a spec, proposal or acceptance criteria so every reviewer evaluates against your stated requirements instead of general best practice. Project context is discovered from files such as `CLAUDE.md`, `.cursorrules` and OpenSpec configs, so reviewers apply your conventions. Teams are configurable from 28 reviewer personas, including named engineers such as Martin Fowler, Kent Beck and Sandi Metz, and you can define your own persistent reviewers or describe ephemeral one-off reviewers inline. The repository also lists multi-model teams and Code Review Maps, which break large changesets into sections with rendered Mermaid dependency graphs and per-file progress tracking. The dashboard adds triage statuses per finding: needs review, in progress, changes made, acknowledged, dismissed.

Installing the OCR CLI and running a first review

The README lists three prerequisites: Node.js 22.5 or newer, Git, and a supported AI coding assistant. Installation is a single global npm command. From v2.1 the project uses Node's built-in SQLite module, so the README states there is no native module to compile and that npm, pnpm and yarn all install cleanly, including under pnpm 10 and later, which blocks dependency build scripts.

npm install -g @open-code-review/cli

After that, initialise OCR inside the project you want reviewed. The README says `ocr init` detects installed AI tools, listing Claude Code, Cursor, Windsurf and 11 more, and configures each one automatically.

cd your-project
ocr init

Then launch the dashboard, which the README calls the recommended way to run reviews and browse results. It opens in your browser.

ocr dashboard

If you would rather stay inside your assistant, the README gives slash commands instead. Note the two spellings for different tools.

/ocr:review
/ocr-review
/ocr-review Review against openspec/spec.md

The third form passes a requirements document, which is the requirements-aware mode described above. The README does not document what `ocr init` writes into a repository or how to undo it, so inspect the diff it produces before committing anything.

Where Open Code Review is the wrong tool

The dependency on an external AI coding assistant is the sharpest constraint. OCR does not ship its own model. It drives reviewers through a tool you already have installed, and the README's prerequisite list names that assistant as required. If your team has no supported assistant, or your organisation forbids sending source code to one, the tool has nothing to drive. The second constraint is cost shape. Every reviewer instance is a model call, and the discourse and synthesis stages add more, so a five-reviewer team on a large diff is not the same expense as a single pass. The README does not publish token or cost estimates, so treat multi-reviewer configurations as something to measure on your own diffs before making them the default. Third, the output is advisory. Triage statuses such as acknowledged and dismissed exist because findings need human judgement; a synthesis stage that prioritises feedback does not make the feedback correct. On a small diff in a codebase with no written conventions, the project-context discovery has little to read, and the multi-agent overhead buys correspondingly less.

How this differs from a CI linter or a hosted review bot

The nearest familiar alternative is a deterministic linter plus a hosted review bot. A linter such as ESLint, which this repository itself uses in its own build, applies fixed rules and produces the same result every run. That predictability is the point, and it is also the limit: a linter cannot evaluate your code against a proposal document or notice that a function contradicts a convention written in prose in `CLAUDE.md`. Open Code Review takes the opposite approach. Its reviewers are probabilistic, requirements-aware and context-aware, and the discourse stage exists precisely because a single model pass is not reliable. The trade is reproducibility for coverage of things rules cannot express. Compared with a hosted review service, the difference is where the work happens. OCR is a CLI you install globally and run against a local repository, with a dashboard served from your machine, and it posts to GitHub only as an explicit step from the review round page, in either a Post Team Review mode or a Generate Human Review mode that rewrites findings into a single voice following Google's code review guidelines. A hosted service owns the pipeline; here you own the invocation.

Maintenance, upgrades and the Apache-2.0 licence

The repository is not archived, and its last push was on 2026-07-28, which is recent enough that the codebase is moving. The release cadence visible in the release list is roughly monthly: v2.3.0 on 2026-06-15, v2.4.0 on 2026-06-28, v2.5.0 on 2026-07-28. The README has an Updating OCR section in its table of contents, though the body is truncated in the published README view, so check that section before scripting an upgrade. The published CLI package is `@open-code-review/cli`, which is what the global install command targets; the repository root `package.json` is private and versioned separately at 1.10.4, so the CLI version and the repository version are not the same number and you should not compare them. The project is Apache-2.0 licensed, which permits commercial use and modification and includes an explicit patent grant. Apache-2.0 also carries notice and attribution obligations, so redistributing a modified copy means preserving the licence and notices. That is a summary of the licence text, not legal advice; read the LICENSE file for the terms that bind you.

Editorial conclusion

Adopt Open Code Review if your team already runs an AI coding assistant and wants a second, structured pass over diffs before a human reviewer opens them. Skip it if you have no supported assistant installed, since the reviewers are driven through that tool, or if you want a hosted service with no local setup. Before committing, verify that `ocr init` detects your specific assistant, that Node is at 22.5 or newer, and that the reviewer personas you pick produce findings you would actually act on.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. spencermarx/open-code-review on GitHub