AI code review that reads the repository, not just the diff.

After CI passes, the PR Reviewer reads each pull request against your architecture, conventions, and documentation at that commit, and posts findings by severity as a normal GitHub review. Read-only on code; a fix is a separate Session a person starts.

CI passes
Reviewer reads the repository
Findings by severity
Fix on request
A person merges

Review a merged pull request, live Watch the demonstration

Thirty minutes with the founder. One repository, read-only, is all it needs.

Why pull request review is the bottleneck

Diffs arrive faster than anyone can read them

AI writes more code. The review queue is where it waits.

Review quality depends on who is free

The conventions live in review comments nobody can search.

The last AI reviewer got switched off

It commented on everything and knew nothing about this codebase.

Demonstration

Code review

Echelar reviews the pull request. A person starts the fix.

The PR Reviewer reads the repository and its documentation at the commit, posts its findings by severity with the convention each rests on, and a person decides what happens next.

Demonstration — authored data · fixes start from the echelar label or the Reviews page

Starts when visible

github.com / acme / billing-console / pull / 517

Private

acme/billing-consolePrivate

☆ Star⑂ Fork

Prevent duplicate invoice retries #517

Openmaya-k wants to merge 3 commits into main from fix/retry-focus

All checks have passed · 12 successful checks at 3f2b9c

echelarbotreviewedat 3f2b9c

◯

Changes requested

2 findings · 1 warning · 1 nitpick

apps/billing/retry-dialog.spec.tsxLine 72

71 await retryButton.click();
72 + expect(dialog).toBeVisible();

WarningThe retry path never asserts that focus returns to the dialog heading; keyboard navigation can regress.

Convention · DOCS/patterns.md › Dialog focus contract

apps/billing/retry-dialog.tsxLine 48

NitpickThe idempotency key is built inline here; apps/billing/idempotency.ts already exports retryKey() for this path.

Convention · ARCHITECTURE.md › Billing idempotency

maya-k added the echelar label · fix Session requested

echelar added 1 commit · a1c9f0 Assert focus returns to the dialog heading · +12 −1

echelarbotapproved these changesat a1c9f0

Approved · findings resolved

The focus assertion returns to the dialog heading and the retry key uses retryKey().

maya-k merged commit a1c9f0 into main

Sequence description

Required checks pass on pull request 517 in acme/billing-console.
The PR Reviewer reads the repository at that commit: DOCS/patterns.md, ARCHITECTURE.md, and apps/billing/retry-dialog.tsx.
It posts one GitHub review, Changes requested, with two findings by severity and the convention each rests on.
A person on the team, maya-k, adds the echelar label to the pull request. That starts a separate fix Session.
The fix Session, with its own short-lived token bound to this pull request, pushes commit a1c9f0 to the branch.
The PR Reviewer reads the new commit and approves the pull request: findings resolved.
maya-k merges the pull request.

Demonstration on a fictional Acme repository — authored data.

How the PR Reviewer reads a pull request

Grounded before it is enabled: It reads the repository and its documentation at the exact commit. If you choose, it rehearses on pull requests you already merged, and you read those private rehearsal reviews before you turn it on.
Findings by severity, after CI: Critical, warning, suggestion, nitpick — posted as one GitHub review once the pipeline has spoken.
Read-only on code: The Reviewer's token cannot push a commit or touch a branch. When it requests changes, a person starts a separate fix Session — from the Reviews page, or automatically by adding the echelar label to the pull request. That Session pushes a commit with its own short-lived token, and review starts again.
Every finding cites its source: Each finding names the file and the documented convention it rests on, so agreeing or dismissing takes a glance, not an argument.

Pull request review, before and after Echelar

	Without Echelar	With Echelar
Where review time goes	Senior people re-check what a machine could check.	People read the findings that need judgment.
Who catches convention drift	Whoever remembers the rule that day.	The Reviewer, grounded in the repository's documented conventions, every time.
Fix cycles	Check out the branch, fix, push, wait.	Add the echelar label; the fix returns as a new commit for review.

Same job, on your repository.

Review a merged pull request, live

AI code review FAQ

How noisy is it?

Only critical and warning findings request changes; suggestions and nitpicks are comments. Because it waits for CI, it never repeats what the linter or the tests already said.

How is this different from CodeRabbit or Copilot review?

It is grounded in your repository's own documentation at the commit under review rather than a rulebook of its own, it can rehearse on merged pull requests before you enable it, and it posts one review after CI instead of a comment on every push.

What does it know about our conventions?

Whatever your repository documents — architecture notes, ADRs, contributing guides — evaluated at the commit under review. Conventions nobody wrote down it cannot know, and it says so rather than inventing policy.

What can the App do in our repository?

Read code and post reviews. The Reviewer's own token cannot push. A write-capable token exists only for a fix Session a person started, scoped to one repository and bound to one pull request's branch. Nothing merges.

Does it replace our reviewers?

It reads first, so they judge instead of proofread. Approval stays where it is.

What does it cost?

Echelar is launching now. Early teams work directly with the founder and agree pricing together.

Bring the real one.

Pick a pull request you already merged. We point the PR Reviewer at it on your repository, and you compare its findings with the review it actually got.