Review Coach —  Coach, not comment bot Desktop · macOS · Linux · Windows

Not another comment bot. A coach for the reviewer.

Paste a pull request. Get a few sharp questions about it. You write the review.

Request access → How it works
01 / The review

Questions, not verdicts

Review Coach fixtures/coaching_demo.rs
coaching_demo.rs+ added
fn · snake_caseverbs · get / fetch / build
Coaching3 cards · this file
claritycoaching_demo.rs:24

get_user removes the entry it looks up. Would a caller reading the name expect a delete?

strategiccoaching_demo.rs:43

first_score panics on an empty slice. Could returning an Option define the error out of existence?

tacticalcoaching_demo.rs:78

build_report takes a validate flag, so it does two jobs. Would two functions leave the next change easier?

01Question-shaped
02Anchored to a line
03Accept · Edit · Dismiss

Illustration. The code is from the app's own test fixture; the questions are written to show the shape of a card.

02 / Positioning

What a bot can't copy

CodeRabbit, Copilot and chat assistants post comments on the diff. Review Coach does the opposite, on three axes a comment bot cannot copy without becoming a different product.

01

It coaches. It does not conclude.

No verdictsNever submits

The output is questions for a human, not rulings on a diff. At most it fills your own pending review, which only you can see, edit and submit.

02

The code is the style guide.

No rulesetInferred from the repo

Naming conventions come from the whole existing codebase: verb vocabulary, affixes, casing per kind. Only drift from the repo's own habits is flagged. There is nothing to import or argue with.

03

Tactical vs strategic.

OusterhoutA Philosophy of Software Design

Does this change add a special case or remove one? Deepen the module, or push complexity onto its callers? Leave the next change easier, or harder?

03 / Restraint

Less is the product

A paragraph per hunk would make it the noise it is trying to beat. So the prompts are hard-capped per file and per pull request, and the cap does not lift when the PR gets bigger.

Every card has to earn its place against the cost of one more thing to read. A clean function should get none.

3
Cards per file, at most
0
Reviews submitted for you
0
External style rules
3
Coaching providers
04 / How it works

One pull request, start to finish

Fetch

Paste a PR

A PR URL or owner/repo#123. The metadata and description come through gh, then a blobless clone and gh pr checkout put the whole repo on disk.

src-tauri/src/github.rs
Diff

Separate the change

A per-file unified diff: what this PR does, apart from the codebase it lands in.

src-tauri/src/diff.rs
Infer

Learn the house style

Read the whole repo for its de-facto casing and verb habits per kind, then flag only where this PR drifts from them.

src-tauri/src/conventions.rs
Overview

Read the whole PR

One reading of the full change before any single file is coached, so every card knows what the PR is for.

prompts/overview-system.md
Coach

Deal the cards

An Ousterhout-anchored prompt per file. At most three question-shaped cards each, under a ceiling for the whole PR.

src-tauri/src/coach.rs
Decide

Keep your judgment

Accept, edit or dismiss each card. What you keep exports as a clean markdown review, ready to paste.

src-tauri/src/review.rs
Send

Pending, not posted

Or send the kept comments into your own pending GitHub review, on their diff lines. Only you see it until you submit.

src-tauri/src/send.rs
05 / Card tags

Four kinds of question

A · strategic

System design

What the change optimises for, and whether it leaves the next change easier or harder.

Is this module getting deeper, or pushing complexity onto its callers?

B · tactical

The quick fix

A shortcut the next change will have to work around.

Does this add a special case where the general one would do?

C · convention

House habits

A name that breaks the repo's dominant convention, measured against the repo's own code.

Everything else here says fetch_. Why does this one say load_?

D · clarity

One clear whole

Name, comment and code telling the same story, so the next reader does not have to guess.

Does the comment say something the code cannot?

Principle

You keep your judgment.

Nothing reaches the PR's author until you submit it. Send to GitHub carries only the comments you kept, exactly as you edited them.

01The repository is the authority
02Restraint is the feature
03Offline is not a degraded mode
04It learns from your decisions
06 / Learning

It gets sharper with you

01

Warm-upAt PR load

When a PR opens, up to three due cards from the built-in review library: the questions worth asking before you start. Dismiss it in one action; it never blocks the review.

02

DrillOn a schedule

A separate session over the same library, on a spaced-repetition schedule. Grade each card and the schedule decides when it comes back. The library covers system design and how to write a review comment.

03

Your decisionsStored locally

Every accept and dismiss is remembered in a local database and makes the coach sharper for your repos, instead of a general-purpose ruleset tuned for someone else.

07 / GitHub

Send to your pending review

I

Via gh

Default · no setup

The app writes the pending review with the same gh login it already uses to load pull requests. Every repo you can reach, no key.

Best when you review from your own machine.

II

Via the Review Coach GitHub App

Hosted · private for now

Authorize the App once and it writes the pending review as you: GitHub shows your avatar with the App's badge. The desktop app sends only what you kept, with a personal upload key.

It acts as you on purpose: GitHub shows a pending review only to its author, so a bot's draft would be invisible to you.

Pending means pending. You submit, or nobody does.

Read the comments again in the pull request itself, edit or delete any of them, and submit when you are ready. The tool never submits a review.

Have access? Open the GitHub App →
08 / Providers

Your model, your call

01

Claude API

Hosted

The Anthropic API, with your own key in ANTHROPIC_API_KEY.

02

LM Studio

Fully offline

Any local OpenAI-compatible server. No key, no network. Test the connection and pick the loaded model in settings.

03

Claude Code CLI

Local CLI

The Claude Code command-line tool already on your machine, with its own sign-in.

Offline is first-class. Every desktop capability works with a local model and no network. A feature that only works in the cloud counts as a regression.

09 / FAQ

Questions

Does it post comments for me?
No. It never submits anything. If you use Send to GitHub, your kept comments go into your own pending review, visible only to you until you submit it on GitHub.
Where does my code go?
The repository is cloned to your machine. With LM Studio nothing leaves it. With the Claude API or the Claude Code CLI, the diff and its context go to that provider for coaching. Reviews, card states and your feedback live in a local SQLite database.
Why so few prompts?
Because sparsity is the product. At most three cards per file and a hard ceiling per pull request. More output would make it the noise it is trying to beat.
Which conventions does it check?
Only the ones your repository already follows. It infers naming (verb vocabulary, affixes, casing per kind) from the existing code and flags where the PR drifts. There is no ruleset to configure.
What do I need to run it?
gh installed and authenticated, git, and one coaching provider. It runs on macOS, Linux and Windows.
Can I download it?
Not yet. Review Coach is not packaged or published. Ask Consensus Labs for access.
10 / Access

Review your next PR with a coach.

Review Coach is in early access and built by Consensus Labs, an engineering studio in Amsterdam.

Request access → Consensus Labs ↗
Once you have the sourcesh
$ gh auth status
$ npm install
$ npm run tauri dev
# then paste a PR URL, or owner/repo#123
01gh, authenticated
02git · Node 18+
03Rust stable
04One coaching provider