How to Set Up Automated PR Review in Your GitHub Workflow (2026)

TL;DR: Automated PR review means every pull request is checked by machines — before a human opens the diff — and cannot merge until those checks pass. You build it in three layers: deterministic gates (lint, type-check, tests, security scans), AI review that reads the code, and behavioral verification that actually runs the change in a browser. The critical detail most teams miss: a check only blocks a merge once it's a required status check in your branch protection rule. screencli is the behavioral layer — it opens your preview deploy on every PR, clicks through the change, and posts a pass/fail verdict you can require before merge.

What is automated PR review?

Automated PR review is the set of checks that run on a pull request without a human triggering them, gating the merge until they pass. It's the screening layer that runs before a person reads the diff — so reviewers spend their attention on judgment, not on catching mechanical failures a machine can find consistently.

This matters more every month because the volume of code hitting the review queue is climbing fast. According to Faros AI's 2026 study of over 22,000 developers, teams with heavy AI adoption merge 98% more pull requests while PR review time rose 91% — the queue, not the keyboard, is now the constraint. And the code flooding it is riskier: a CodeRabbit analysis of 470 PRs found AI-generated code carries 1.75x more logic errors than human-written code, and Veracode's 2025 research found AI-generated code is 2.74x more likely to introduce cross-site scripting vulnerabilities. Automation is how you keep the bar up without drowning your reviewers.

The three layers of an automated PR review pipeline

A complete pipeline stacks three kinds of checks. Each catches a different class of problem, and the layers are cheapest-first so you don't spend AI tokens or browser time on a PR that fails lint.

The first layer is table stakes. The second reads the code. The third is the one most pipelines are missing — because reading a diff, even with perfect repo context, can't tell you whether the running app behaves correctly. The rest of this guide sets up all three.

Step 1 — Require a pull request before merging

Nothing else works until direct pushes to main are blocked. Go to Settings → Branches (classic branch protection) or Settings → Rules → Rulesets (the newer, composable system GitHub now recommends) and add a rule targeting your default branch.

Enable, at minimum:

• Require a pull request before merging — no commits land on main except through a PR. This is the foundational rule that makes every other check possible.
• Require approvals — set to 1 as a baseline, or 2 for anything touching build tooling, CI YAML, or dependency manifests.
• Dismiss stale pull request approvals when new commits are pushed — critical for AI-assisted PRs, where an agent can regenerate large chunks of the diff after it was approved.
• Do not allow bypassing the above settings — the one checkbox most teams skip. Without it, admins and CI service accounts can route around every rule you just set.

Rulesets compose, so you can layer an org-wide rule (squash-only, no force pushes) with repo-specific required checks. As GitHub's docs put it, "multiple rulesets can apply at the same time, so you can be confident that every rule targeting a branch will be evaluated."

Step 2 — Add deterministic checks as required status checks

Now wire your CI. Put a workflow at .github/workflows/pr-checks.yml that triggers on pull_request and runs your fast, deterministic gates — lint, type-check, unit tests, and security scans. Order them cheapest-first so a formatting failure doesn't wait on a full test run.

Then make them enforce. In the same branch protection rule or ruleset:

1. Enable Require status checks to pass before merging.
2. Search for and select each check by its exact job name — GitHub matches on the literal string, so a renamed job silently stops being enforced.
3. Enable Require branches to be up to date before merging so a PR can't pass against a stale base and then break main on merge.

For AI-assisted codebases, treat SAST, secret scanning, and dependency review as non-negotiable required checks — the elevated vulnerability and secret-leak rates in AI-generated code make pre-merge scanning a necessity, not a nice-to-have.

Step 3 — Layer in AI review

AI review reads the code and flags what static rules can't express — logic bugs, cross-file regressions, risky patterns. There are two setup patterns, and you pick one before you pick a tool:

• GitHub App / OAuth installs (e.g. CodeRabbit, Copilot's native reviewer): zero pipeline YAML — you install the app, grant repo access, and it starts commenting.
• GitHub Actions installs (e.g. PR-Agent, custom scripts): you add an explicit workflow, wire secrets, and scope the trigger with concurrency and path filters so force-pushes don't spawn duplicate runs.

Whichever you choose, run it advisory first. As one 2026 CI/CD setup guide puts it bluntly: "AI review is advisory until you make it a required status check. The merge gate lives in branch protection rules, not in the AI tool." Watch it post on real PRs for a week or two, confirm it delivers a stable check on the latest commit every time, and only then add it to your required-checks list. Promoting a noisy reviewer to required on day one just blocks your team. For a deeper checklist on reviewing agent output, see how to review AI-generated pull requests.

Step 4 — Add behavioral verification with screencli

Here's the gap the first two layers leave open: static tools read your code, but nobody runs it. A diff can look perfectly reasonable while the button is wired to the wrong prop, the form submits to a stale endpoint, or a shared-component tweak quietly breaks four other screens. Reading answers "is this plausibly correct?" — it can't answer "does the change actually work?"

screencli is the automated reviewer that uses the app. You install the screencli GitHub App and pick which repos it watches. When a PR opens, screencli reads the diff, plans the browser checks that matter for that change, runs them against your preview deploy — Vercel, Netlify, or Cloudflare Pages, picked up automatically from your GitHub deployments, never touching production — and posts a pass/fail comment with a recording of what happened. You don't write test files; the AI decides what to exercise based on what changed. Add that check to your required-status list and no PR merges until the change has been proven to work in a browser. See how screencli reviews your next PR →

Step 5 — Route ownership and add a merge queue

Two final pieces make the pipeline scale:

• CODEOWNERS. Add a .github/CODEOWNERS file mapping sensitive paths (/src/auth/, /infra/, /.github/workflows/) to the teams that own them. GitHub then auto-requests the right reviewers whenever a PR touches those files, instead of whoever approves first.
• A merge queue — for genuinely busy default branches. It serializes merges, revalidates each PR against the latest base, and, in GitHub's words, "ensures the branch is never broken." One catch: your CI must subscribe to the merge_group event, not just pull_request. If your tests don't run on merge_group, you don't have a merge queue — you have a hope.

Common mistakes to avoid

• Assuming an AI reviewer that comments is enforcing. It isn't until it's a required status check. Watch your merge box, not the comments.
• Forgetting "require branches to be up to date." With agents opening PRs in parallel, stale-base merges are a leading cause of broken builds.
• Requiring a flaky check. A check that intermittently fails to report will block every PR. Confirm delivery before you require it, and keep a documented way to roll the ruleset back to advisory.
• Gating on reading but never running. Deterministic gates and AI review both inspect code statically. Without a behavioral layer, "all checks green" can still ship a broken flow — the exact failure mode that's becoming the new bottleneck as AI writes more of the code.

FAQ

How do I set up automated PR review in GitHub? Protect your default branch with "Require a pull request before merging," then add the checks that must pass as required status checks: deterministic gates (lint, type-check, tests, SAST), an AI reviewer, and behavioral verification. Automated review only blocks a merge once it's a required status check.

What's the difference between a required and an advisory check? A required status check blocks the merge button until it succeeds; an advisory check comments or annotates but never gates the merge. The gate lives in your branch protection rule or ruleset, not in the tool.

Should AI code review be a required check? Run it advisory first, confirm it delivers a stable, trustworthy check on every PR, then promote it to required. Making a noisy reviewer required on day one blocks your team.

Do automated checks replace human reviewers? No. They remove the mechanical load so humans focus on architecture and business-logic judgment. See screencli vs CodeRabbit vs Greptile for how the layers fit together.

How do I stop AI-generated PRs from breaking main? Require branches to be up to date (or use a merge queue), require deterministic checks plus behavioral verification that runs the app, and dismiss stale approvals when new commits are pushed.