◎
Per-file coverage outcomes
Large-change orchestration (opt-in) emits explicit per-path outcomes: reviewed, partially-reviewed, excluded-by-policy, unsupported, and budget-exhausted. Incomplete enumeration never reports a fully reviewed plan.
Open source · Alpha · Repository-aware
AI code review.
Your models. Your standards. Your control.
Review pull requests with repository-owned knowledge, configurable review stages, and explicit coverage. Run in your own GitHub Actions environment or locally, and decide what it can publish and learn.
Explicit coveragePer-file outcomes including incomplete and budget-exhausted.
Stable finding IDsTrack disposition across runs without assuming omission means fixed.
Trusted contextPath-scoped lenses, stages, and repository learnings you approve.
Bounded diagnosticsZero-write
doctor and plan previews before you publish.Demonstrable controls
Review behavior you can inspect and reproduce.
Capabilities below ship in the open-source engine today. Defaults and opt-in gates are noted where release posture matters — see fixture walkthroughs for reproducible examples.
◇
Stable finding identities
Incremental reviews derive lifecycle states (new, still-present, fixed, outdated, uncertain) from stable fingerprints. A later response omitting a concern is not treated as proof the defect is fixed.
↗
Learning lifecycle
Proposed learnings appear in the review result → draft learning PR → maintainer approval on the trusted base → future selection for matching paths. Thread resolution and learning approval are separate from code correctness.
⌘
Trusted lenses & stages
Configure path-scoped stages, categories, and trusted-base context. Symbol-aware source context is opt-in trusted-base policy, disabled by default.
↔
Separate write switches
Independent controls for analysis, comment publication, automatic approval/request-changes, learning proposals, learning PRs, @sensei conversations, and artifact retention.
{""}
Bounded diagnostics & plans
review-sensei doctor and review-sensei plan perform zero-provider-call, zero-write previews of configuration, stages, budgets, and skip reasons before you publish.
How it works
One pull request. Several specialist perspectives.
Instead of asking one model to "review this code," ReviewSensei decomposes review into focused stages and then synthesizes the results.
- 1Build context. Load the diff, relevant files, repository policy, architecture notes, and approved learnings.
- 2Run specialists. Each reviewer looks for a narrower class of failure with its own criteria.
- 3Validate structure. Enforce JSON/schema contracts, diff-location bounds, and configured evidence checks. This is not independent verification that every finding is correct.
- 4Export a clean review. High-signal findings and a final verdict are written to a validated artifact ready for your chosen integration.
Correctness reviewer
Logic, error paths, state transitions, edge cases
Architecture reviewer
Boundaries, coupling, maintainability, design drift
Security reviewer
Trust boundaries, authz, data exposure, risky patterns
Performance reviewer
Scaling risks, hot paths, unnecessary work
Illustrative synthesis3 findings · explicit coverage fields · no fabricated quality score
See it concretely
Fixture walkthroughs you can reproduce.
The synthetic evaluation/v1 corpus demonstrates review output, thread follow-ups, finding disposition, learning proposals, and partial coverage — each labeled as fixture or illustration with copyable commands.
✦
Off-by-one finding
A sanitized pagination change produces a specific correctness finding with deterministic fixture replay.
👀
@sensei follow-up
Bounded, thread-aware replies when conversation controls are enabled — shown as an illustrative thread, not a live PR.
↗
Disposition & learning
Stable finding fingerprints and maintainer-approved learnings are separate artifacts with separate lifecycles.
◎
Partial coverage
Budget-limited reviews retain valid findings, surface explicit coverage fields, and withhold approval — no fabricated confidence score.
Start small
Install it where your code already lives.
ReviewSensei supports customer-owned cloud and local execution with the same reviews, learning proposals, artifacts, and multi-turn PR conversations.
# Install the ReviewSensei GitHub App
Open the ReviewSensei GitHub App on GitHub →
Need a custom or self-hosted App? Read the GitHub App registration guide.
Open the ReviewSensei GitHub App on GitHub →
Need a custom or self-hosted App? Read the GitHub App registration guide.
Your model credentials stay yours
Configure your provider in your own execution environment. ReviewSensei should not need to become the owner of your model account.
Your review memory stays portable
Repository-specific learnings can live in Git so they remain reviewable, versioned, and independent from any individual LLM vendor.
Documentation
Everything you need to get started.
Installation, configuration, data handling, security, and architecture docs live in the public repository.
⌁
Installation guide
Install from source, configure your provider, and run your first review. Covers local Ollama, Ollama Cloud, and OpenRouter.
◇
Security & data handling
The core does not persist raw prompts or provider responses. Published comments, artifacts, approved learnings, and your model provider have separate retention boundaries.
⌘
Architecture & contracts
Provider-neutral review engine, structured stages, versioned JSON schemas, and public compatibility guarantees.
Open source
Keep the reviewer inspectable. Keep the judgment yours.
Inspect the reviewer, choose the models, own the memory, and evolve the workflow with your repository instead of handing institutional knowledge to another closed review service.
What if
input.couponis invalid or expired?