How Cerbie works

Cerbie is Lleverage’s pull request reviewer. This page covers what it does, what it reads before it comments, and what it trusts. To shape how it reviews your project, see Configuring a repository.

In short

• Cerbie is a GitHub App (cerbieai[bot]) installed on every lleverage-ai repository. It reviews PRs when they’re opened or marked ready, and again on each push.
• It runs on Cloudflare. Reviewers read the exact commits through a read-only git mirror. They never install, build or run your code.
• Several reviewers work in parallel, and a separate verifier re-checks every critical and should-fix finding against the code before it’s posted.
• It approves or requests changes, like a human reviewer. Reply on a finding and Cerbie re-reviews it with your reply in mind.
• How it reviews comes from three places: Cerbie’s review policy, organisation instructions, and your repository’s guidance (.cerbie/, AGENTS.md, CLAUDE.md and similar files).
• Each repository is live (posts to GitHub), shadow (reviews, but results only appear in the dashboard) or off.

How a review runs

A typical review takes three to four minutes from push to verdict, and the summary is usually posted within the first minute.

1. Gate. The webhook is verified, then checked against .cerbie/config.yaml from the base branch. Drafts, ignored authors and labels, and cerbie: skip stop here.
2. Coordinate. Each PR has one coordinator. It batches quick pushes, and if a newer commit arrives mid-review it cancels the old review rather than spending time on stale code.
3. Gather context. Everything listed below is collected while the git mirror syncs the exact base and head commits.
4. Triage. Deterministic rules pick the review depth (light, standard or deep) and which specialists run, based on paths, size and risky code patterns.
5. Review in parallel. The summary, the primary reviewer, security, data and contracts specialists, custom checks, dependency and secret checks, and a follow-up of earlier findings all run at once.
6. Verify. Candidates are merged, and restatements of still-open findings are folded into them, so you don’t get the same comment twice. A verifier in a fresh context confirms, adjusts or rejects every critical and should-fix finding.
7. Challenge. If the PR is risky and would otherwise be approved, one more reviewer gets everyone’s notes and looks for failure modes nobody traced.
8. Publish. If the PR moved on in the meantime, nothing is posted. Otherwise Cerbie posts one review with inline comments, completes the check runs and updates the summary.

Architecture has the details, including review tiers and models.

Where context comes from

Reviewers start with a brief, then use read-only tools (read_file, grep, find_files, diff_file, git_log) to explore the whole repository at the exact commits, not just the diff.

Source	What Cerbie gets from it
The change	Title, description, commits, files and patches, numbered so findings point at exact lines
The codebase	A shallow git mirror at the base and head commits, so reviewers can follow callers, types and tests outside the diff
The Linear ticket	Linked by a key like LLE-1234 in the title, branch or description. Cerbie checks the change does what the ticket asks
CI and discussion	Check status (Cerbie leaves builds and tests to CI) and the PR conversation so far
Your guidance	.cerbie/, plus AGENTS.md, AGENT.md, CLAUDE.md, .cursor/BUGBOT.md, .github/copilot-instructions.md and .github/instructions/*.instructions.md
Learnings	Facts Cerbie has learned from replies in this repository, and organisation instructions from the dashboard
Earlier findings	On follow-up reviews, so it checks whether they’re fixed and doesn’t repeat itself
Package registries	For new dependencies: existence, age, deprecation and licence. Metadata only; nothing is installed

What Cerbie trusts

• Rules come from the base branch. A PR can’t change the .cerbie/ rules it’s reviewed against. Changes to .cerbie/ apply to reviews after they’re merged.
• PR content is evidence, not instructions. Code, comments, tickets and tool output can’t tell Cerbie to approve.
• Credentials stay put. GitHub write access never leaves the Worker. The git mirror only gets short-lived, read-only, single-repository tokens.
• Incomplete never approves. If a required stage fails, the review says so and lists the gap in its coverage table.

Where things are

Dashboard	app.cerbie.ai, sign in with GitHub (any lleverage-ai member)
Source	lleverage-ai/cerbie: the review engine, prompts and review policy
On GitHub	Comments come from cerbieai[bot]; mention @cerbieai on a PR to ask a question or run a command
CLI	npm install -g cerbie, then cerbie review. See The Cerbie CLI
Feedback	Reply on findings, rate them in the dashboard, and post misses in #devs. Misses go into the evaluation corpus