# Open Code Review puts a tech lead above three independent reviewer teams

> A dashboard-driven multi-agent reviewer where personas debate findings before anything is synthesised, findings carry a triage status, and one of two GitHub posting modes rewrites the result into a single human voice. Storage moved to a built-in SQLite module so no compiler is needed.

**spencermarx/open-code-review** — AI-powered multi-agent code review. Simulates a customizable team of Engineers performing code review with built-in discourse.

- Repository: https://github.com/spencermarx/open-code-review
- Stars: 371 · Forks: 36
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/spencermarx-open-code-review

## node:sqlite removed the compiler from the install path

The installation is three commands.

```bash
# 1. Install the CLI globally
npm install -g @open-code-review/cli

# 2. Initialize OCR in your project
cd your-project
ocr init

# 3. Launch the dashboard and run your first review
ocr dashboard
```

The dashboard opens in the browser. Prerequisites are Node.js 22.5 or newer, Git, and an AI coding assistant.

The reason any package manager works is stated as a change of storage backend. From version 2.1 the tool uses the SQLite module built into Node rather than a native dependency, so there is nothing to compile. That matters beyond convenience: package managers that block dependency build scripts, pnpm 10 among them, would otherwise fail at install time. Global installs through pnpm and yarn are called out explicitly as working.

So the practical requirement is a Node version, not a build toolchain. Everything else about the tool is configured by the init step, which detects the installed editors and writes their configuration itself.

## A tech lead orchestrates, and teams are composed independently

The stated problem is that asking one model to review code gives one perspective: a single pass and a single set of priorities. The answer is redundancy plus a hierarchy.

Several reviewer instances examine the code independently. The reasoning is that different attention patterns catch different issues, so what one misses another finds.

The structure places a tech lead role above the team, which orchestrates the review, with each team composition below it holding its own membership. The diagram shows three parallel compositions under the single lead rather than one pool of reviewers, which is what allows the same lead to compare different mixes.

Composition is user-controlled in two directions. You pick which personas appear and how many instances of each, and that default lineup is persisted to a config file rather than being typed at each run. You can also change the composition per review from the dashboard command centre.

Model assignment is separate from persona choice, so the same generalist persona can run on a fast model while a specialist runs on a deeper one, or a single team can mix vendors.

## Debate before synthesis, not findings after

The feature that distinguishes this from running one reviewer several times is discourse.

Reviewers do not simply produce findings and have them collected. They debate them: they challenge assumptions, validate concerns, and raise questions that no single reviewer would have asked. Synthesis comes after that exchange rather than replacing it.

The reasoning is about coverage of reasoning rather than coverage of files. Two independent passes can find two sets of bugs, but only an exchange surfaces the case where one reviewer misread a requirement and the other noticed.

Requirements awareness is the other half. A spec, a proposal or acceptance criteria can be passed in, and every reviewer then evaluates the code against those stated requirements rather than general best practice alone. Reviews can be launched against a spec file in the repository from the assistant, using the same slash command form as a plain review.

Project context comes from the repository itself. Standards are discovered from files such as CLAUDE.md, .cursorrules and OpenSpec configuration, so reviewers apply the conventions already present rather than a generic style guide.

## Two posting modes, and only one of them is a synthesis

Posting to GitHub is offered in two modes from the review round page, and the difference is whether a machine rewrites the output.

Post Team Review publishes the multi-reviewer synthesis exactly as it is. What lands on the pull request is the structured result, including the separate voices.

Generate Human Review asks the model to rewrite all findings into a single natural human voice, following Google's published code review guidelines. The page allows a preview, an edit and saving a draft before anything is posted.

That second mode exists because a pull request comment read as five reviewers arguing is a different artefact from a review comment read as one colleague. It is also the more intrusive option, since it rewrites the findings before a person outside the tool sees them.

Either way the posting step is deliberate. Nothing in the described flow posts automatically on completion; a review round is opened, a mode is chosen, and the result is previewed first.

## Every finding carries a five-state triage field

Review results are browsed rather than read once. The review page holds verdict banners, individual reviewer cards, findings tables and the cross-reviewer discourse for every round.

Findings have a triage status with five values: needs review, in progress, changes made, acknowledged and dismissed. Filtering and sorting are available over them.

Five states is a deliberate compromise. Two would mean done or not done, which forces a reviewer to treat anything they have not looked at as either new work or noise. Five covers the common loop of looking at a finding, starting a fix, coming back to it, deciding it does not apply, and leaving a record of that decision.

The same area covers large changesets through Code Review Maps, which give section-based breakdowns, dependency graphs rendered as Mermaid diagrams, and file-level progress tracking. That is the feature aimed at a diff too big to read linearly, and it is launched from the dashboard rather than from the command line.

## 28 personas in four tiers, and a lineup in .ocr/config.yaml

The team page groups every available reviewer into four tiers: generalists, specialists, famous engineers and custom entries. Each card exposes the full prompt behind the persona, its focus areas and its details, so a reviewer is not a black box with a name.

The famous engineers tier is where the recognisable names sit, including Martin Fowler, Kent Beck and Sandi Metz. The project also allows persistent reviewers of your own and ephemeral ones described inline for a single run, which is the escape hatch for a review that needs a role nobody has written yet.

The default lineup, meaning which personas appear on every review and how many instances of each, is stored in a config file under the ocr directory inside the project. Keeping it in the repository rather than in user settings means a team shares its review composition through version control.

Reviewers are also created and edited from the dashboard, and persona metadata can be synced rather than retyped. The repository root carries a matching set of integration directories for several assistants, plus an MCP configuration file.

## An Nx monorepo on pnpm, and two version numbers that differ

The build system is an Nx workspace with pnpm, declared at pnpm 9.15.0 with Node 22.5 or newer required. Tasks are fanned out by target rather than by path: build, test, lint and e2e each run across the workspace, with separate tasks for the CLI, the dashboard API and the dashboard UI.

End-to-end coverage uses Playwright, unit coverage uses Vitest, and the build goes through esbuild with the SWC toolchain registered for Node. That is a normal modern monorepo setup, and the practical consequence is that contributing needs the workspace rather than a single package.

One inconsistency is worth flagging for anyone pinning a version. The published CLI package is scoped as a separate artefact from the root manifest, and the releases are tagged in the 2.x range while the root package version reads 1.10.4. A slash command that expects a particular command shape is therefore worth checking against the version actually installed.

The root manifest is also marked private, which is consistent with the CLI being the only distributed artefact.

## Conclusion

This fits a team that wants a second opinion on every changeset without spending reviewer attention on the mechanical findings, and that keeps its conventions in CLAUDE.md or .cursorrules where the tool will read them. It does not replace human review, which the project says plainly, and it will not help if your requirements are not written down, because requirements-aware review depends on a spec being passed in. Two things to check on your own machine: that the version you install matches what your editor's slash command expects, and whether you want the raw multi-reviewer synthesis posted publicly or the rewritten single-voice version.

## FAQ

### How do I install and run Open Code Review?

Install the CLI globally with npm install -g @open-code-review/cli, change into your project, run ocr init, then run ocr dashboard which opens the dashboard in a browser. Node.js 22.5 or newer, Git and an AI coding assistant are the prerequisites.

### Why does Open Code Review work with any package manager?

From version 2.1 it uses the SQLite module built into Node instead of a native dependency, so there is no native module to compile and nothing for a package manager's build-script policy to block.

### How many reviewer personas ship with Open Code Review?

28, grouped into four tiers: Generalists, Specialists, Famous Engineers and Custom. The Famous Engineers tier includes Martin Fowler, Kent Beck and Sandi Metz.

### Can Open Code Review review against a specification?

Yes. A spec, proposal or acceptance criteria can be passed in so every reviewer evaluates against stated requirements rather than general best practice, and a review can be launched against a repository spec file from the assistant.

### What are the two ways Open Code Review posts to GitHub?

Post Team Review publishes the multi-reviewer synthesis as it stands, and Generate Human Review rewrites all findings into a single natural human voice following Google's code review guidelines. Both allow a preview and editing before posting.

### Does Open Code Review replace human code review?

No. The stated goal is to reduce the burden on human reviewers by catching issues earlier, so that human review is faster and focused on the things machines cannot catch.

## Sources

- [Issues](https://github.com/spencermarx/open-code-review/issues)
- [License: Apache-2.0](https://github.com/spencermarx/open-code-review/blob/main/LICENSE)
- [README](https://github.com/spencermarx/open-code-review/blob/main/README.md)
- [Releases](https://github.com/spencermarx/open-code-review/releases)
- [spencermarx/open-code-review on GitHub](https://github.com/spencermarx/open-code-review)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spencermarx-open-code-review