> ## Documentation Index
> Fetch the complete documentation index at: https://www.bugzy.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# PR review

> Bugzy reviews your pull requests from multiple perspectives and posts one prioritized review comment — on open and on every new commit.

When a pull request is opened in a connected repository, Bugzy can review it the way a
thorough senior engineer would — across several perspectives at once — and post a single,
prioritized review comment. When a new commit is pushed to that PR, Bugzy reviews just the
new changes and adds a follow-up comment. This works for any pull request, whether a human
or an AI coding agent opened it.

This is **opt-in per team** — Bugzy does not review pull requests until you turn it on.

## What a review covers

Bugzy fans out several focused reviewers, each looking at the change through one lens, and
merges their findings:

| Lens         | Looks for                                                                          |
| ------------ | ---------------------------------------------------------------------------------- |
| Completeness | Missing cases, unhandled errors, half-wired features, work left unfinished         |
| Simplicity   | Over-engineering, needless complexity, duplication, a simpler shape                |
| Security     | Auth and tenant isolation, secret handling, input validation, unsafe input         |
| Tests        | Untested new behavior, missing regression tests, brittle or empty assertions       |
| Docs         | Whether docs were updated to match a behavior, config, or API change               |
| Rollout      | Migrations, config and feature-flag changes, backward compatibility, deploy safety |

Bugzy scales the number of reviewers to the size and content of the PR — a small change
gets a couple of reviewers, a large or sensitive one gets more (up to six). Reviewers read
beyond the diff — parent types, call sites, sibling migrations, and the consumers of any
changed contract — which is how they catch issues the diff alone doesn't show.

## The review comment

Every review is posted as one comment with:

* a short **TL;DR** naming the most important blockers,
* findings grouped by lens, each tagged **critical**, **important**, or **nit** with a
  `file:line` reference and a concrete fix,
* a one-line **verdict** on merge-readiness.

On a new commit, Bugzy posts a new comment scoped to just the new changes — it does not
edit the earlier review.

## Enabling PR review

<Steps>
  <Step title="Connect a source-control integration">
    Connect GitHub (or GitHub Enterprise Cloud) so Bugzy can see your repositories and the
    pull requests opened in them.
  </Step>

  <Step title="Add a “Review pull requests” automation">
    In your team's automations, add an event automation on the GitHub **Pull Request**
    event for the repositories you want reviewed. That automation is the opt-in — without
    it, Bugzy reviews nothing.
  </Step>

  <Step title="Open a pull request">
    Bugzy reviews the PR and posts its comment. Push a new commit and it reviews the
    increment.
  </Step>
</Steps>

## Scope and limits

* **Connected, non-fork repositories only.** Pull requests from forks are not reviewed.
* **Reviews are comments, not merge gates.** Bugzy posts findings; your team decides. A
  review never pushes code or edits your files.
* **One comment per event.** Bugzy does not resolve or edit earlier review comments.

## PR review and verify-changes

PR review and [verify-changes](/docs/capabilities/verify-changes) are complementary and can run
on the same PR: verify-changes *runs your tests* against the change, while PR review *reads
the code* and reports design, correctness, security, and rollout findings. Together they
cover both "does it pass the tests" and "is it good code".