AI code review
for GitHub App
PR Agent focuses on GitHub App workflows: automatic pull request review, structured summaries, policy-aware feedback, and operational endpoints for real-world rollout.
Turn webhook intake into review output that actually fits engineering flow.
Not just a summary generator.
Built for real PR/MR review workflows.
PR Agent is built with TypeScript + NestJS and designed around real GitHub and GitLab collaboration paths. It supports automatic review as well as comment commands for Q&A, checks, test drafting, and documentation help.
Reduce repeated AI work.
Keep the review context that matters.
This is not a single review prompt wrapped in a UI. It is a runtime built around triggers, dedupe, policy, metrics, and debugging loops.
View OperationsIncremental Review State
CoreOnly reviews new commits since the previous run, reducing repeated comments and repeated AI work.
Dedupe Protection
RuntimeAutomatic triggers and comment commands both use dedupe windows to avoid duplicate executions after redelivery.
Policy + Process Checks
GovernanceUnderstands workflows, templates, CODEOWNERS, and CONTRIBUTING files, then emits process-aware feedback.
Observability + Replay
OpsExposes health checks, Prometheus metrics, and replay tooling for debugging real webhook traffic.
Incremental Review State
CoreOnly reviews new commits since the previous run, reducing repeated comments and repeated AI work.
Dedupe Protection
RuntimeAutomatic triggers and comment commands both use dedupe windows to avoid duplicate executions after redelivery.
Policy + Process Checks
GovernanceUnderstands workflows, templates, CODEOWNERS, and CONTRIBUTING files, then emits process-aware feedback.
Observability + Replay
OpsExposes health checks, Prometheus metrics, and replay tooling for debugging real webhook traffic.
From webhook setup
to observable runtime.
If you only want a fast validation, start with one real PR. If you want production rollout, keep going until policy, runtime state, and monitoring are in place.
Platform Setup
Choose GitHub App, plain GitHub webhook, or GitLab webhook first, then configure secrets, webhook URLs, and your AI provider.
Review Triggers
Run automatically on PR or MR lifecycle events, or trigger targeted work from the comment thread with commands.
Observe + Tune
Use /health, /metrics, platform health endpoints, and replay tooling to keep the runtime observable and debuggable.
What PR Agent Handles
Features mapped to the real repository.
The homepage copy is now tied to product behavior already present in the repository, not generic agency placeholders.
View CommandsAutomatic PR/MR Review
CoreReview Triggers
Runs on opened, edited, synchronize, and merged events so the first review pass does not depend on manual timing.
Inline Comments + Reports
CoreComment + Report
Supports comment and report modes, with GitHub Suggested Changes where appropriate.
Interactive Command Surface
CommandsComment Thread
Run /ask, /checks, /generate_tests, /describe, and more directly inside PR or MR discussions.
Policy Guardrails
GovernanceRepository Process
Understands templates, workflows, CODEOWNERS, and CONTRIBUTING changes, then emits process-aware feedback.
Multi-provider AI Support
CompatibleProvider Choice
Works with OpenAI, compatible APIs, Claude, and Gemini depending on deployment needs.
Operations Endpoints
OpsHealth + Metrics
Exposes health checks, Prometheus metrics, and replay endpoints for debugging production traffic.
Review output is only part of it.
Commands, policy, and runtime controls matter too.
The PR thread becomes the control surface.
Run /ai-review, /ask, /checks, /generate_tests, /describe, /changelog, /improve, and more directly inside code review discussions.
Only reviews the new commit range so old comments do not get replayed forever.
Can infer bugfix, feature, refactor, docs, and security labels from diff content.
Pre-checks issue and pull request flows against repository templates and process files.
Stores reviewer preference signals through feedback commands and review-thread state.
The PR thread is not just output.
It is also the operator interface.
Auto review is useful as a default pass. Comment commands matter when you need targeted follow-up inside a live discussion.
See WorkflowChoose the integration path first.
Then complete the rollout baseline.
The repository README already gives a practical rollout order: choose platform mode, configure model provider, enable durable runtime state, verify health, then test inside a real PR or MR.
GitHub App
Best overall coverage with a cleaner permission model, making it the preferred path for long-running production use.
GitHub Webhook
A good fit when you want direct webhook integration and a faster first validation for automatic review and commands.
GitLab Webhook
Keeps GitLab support in play and allows review-mode override through headers for platform-specific rollout control.
Do not stop at review output.
Make the runtime observable.
The real question after rollout is whether you can quickly tell if webhook delivery, provider configuration, or platform setup is failing.
From trial run to production.
A more realistic two-step path.
Instead of fake pricing, this section reflects the actual rollout maturity the repository suggests: validate quickly first, then harden for production.
Trial Run
Best for validating one repository and one real pull request before expanding usage.
Baseline
Best for teams that want durable runtime state, policy controls, and operational visibility as defaults.
Built for teams that want AI review
inside normal engineering flow.
These are rollout profiles, not fictional customer quotes. They map the repository capabilities to the kinds of teams that actually need them.
View Commands“We need one review baseline across many repositories and want structured feedback to appear automatically when a PR opens.”
“We want a conservative first rollout, using commands in comment threads before enabling more automatic behavior.”
“We need one toolchain that can support both GitHub and GitLab instead of maintaining separate review surfaces.”
“We care about workflows, templates, and CODEOWNERS changes as much as application code changes.”
“After rollout, the real requirement is observability, because debugging webhook, provider, and runtime issues needs clear endpoints.”
“We need the freedom to switch among providers depending on cost, quality, and deployment constraints.”
Common Questions
These answers are aligned with the current repository README and the sibling web project, not invented marketing promises.
The repository currently supports GitHub App, plain GitHub Webhook, and GitLab Webhook. GitHub App is the recommended path because it has the cleanest permissions model and the broadest tested coverage.
Run PR Agent on a real pull request.
Then decide how far to roll it out.
If you only do one thing, wire a webhook, verify /health, and run /ai-review inside a comment thread. That reveals more than another static mockup ever will.
View Deployment Modes