pulls.review groups a diff by scope before it asks a model about it

The diff is grouped by scope, then reviewed one scope at a time

The one-line description of pulls.review is that pull request review is made simple, and it groups changed files, summarizes what matters, and reviews them one scope at a time. The emphasis on scope is the interesting part, because it is a claim about how review attention should be spent rather than a claim about output quality.

A pull request of two hundred changed lines and a pull request of two thousand changed lines are not the same review problem, and neither is a refactor that touches forty files for one reason. Grouping by scope and working through one group at a time is an answer to that.

The project is a web app at pulls.review, and it is also usable inside GitHub itself. There is an optional userscript that enhances the GitHub interface with pulls.review features, installed by going to pulls.review and scrolling down to the GitHub section.

The author is Anthony Fu, and the project states that it is inspired heavily by Linear's PR review guides. The repository carries a warning at the top of the readme that says heavily work in progress, and that warning is the first thing a reader should weigh. The release history supports the caution and the interest at the same time: v0.3.4 on 2026-10-20, v0.3.3 on 2026-10-13 and v0.3.2 on 2026-10-09.

A monorepo of four packages, one of them reserved

The project is a pnpm workspace with a private root package, and the four packages map to the different ways it can be used.

The app package is the site at pulls.review and the github.com embed. The core package does the fetching, parsing, grouping and summarizing of diffs, and the documentation is explicit that it runs in the browser and in Node, which is what lets the same diff logic serve both the hosted site and the CI action.

The actions package is the CLI that the GitHub Action runs. And the standalone CLI package, named pulls.review, is for reviewing local git changes, with the documentation stating plainly that it is not implemented yet and the name is reserved.

That last entry is worth pausing on, because it is the difference between the project as it is and the project as it is going to be. The local review path is where a tool like this would be most useful for a developer checking their own branch before opening a pull request, and it does not exist yet.

The root package manifest shows the rest of the setup: pnpm 12.14.0 as the package manager, TypeScript throughout, vitest for the test run, eslint with the @antfu/eslint-config, and two scripts that are unusual for a public repository. The prepare script runs a skills experimental_sync command, and there is a skills-lock.json and a skills-npm.config.ts, so the repository treats agent skills as a managed dependency.

The GitHub Action, and why pull_request_target is called out

The experimental CI mode is the part with the security nuance, and the workflow file explains it in a comment. Instead of each reviewer spending their own model key, a workflow analyzes every pull request once and posts the result as a PR comment, and pulls.review picks that comment up automatically for everyone who opens the pull request there.

The example workflow is short:

# .github/workflows/pulls-review.yml
name: pulls.review
on:
  # The analysis only reads the diff through the API and never checks out PR code,
  # so `pull_request_target` is safe here and lets fork PRs get a comment too.
  pull_request_target:
    types: [opened, synchronize, reopened]

permissions:
  pull-requests: write

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: antfu/pulls.review@main
        with:
          api-key: ${{ secrets.VERCEL_AI_GATEWAY_API_KEY }}

The security argument is stated in the comment itself: the analysis only reads the diff through the API and never checks out pull request code, which is why pull_request_target is safe here and why fork pull requests also get a comment. That reasoning is the crux, and it holds only as long as the no-checkout property stays true.

The permissions block is minimal, granting pull-requests: write and nothing else, and the trigger covers opened, synchronize and reopened.

Provider inference, and the CLI under the action

The action is a thin wrapper around the @pulls.review/actions CLI, and the documentation says that CLI works anywhere a GitHub token and a model key are in the environment:

GITHUB_TOKEN=... ANTHROPIC_API_KEY=... npx @pulls.review/actions owner/repo#123

The argument is a repository and a pull request number, so the same command works locally as in CI.

The provider is inferred from the key you pass: gateway for a Vercel AI Gateway token, anthropic, or openai-compatible with a base-url. You can set it explicitly, along with model and locale, when you want to.

Every variable also has a PULLS_REVIEW_ prefixed form, and those take precedence. The listed set is PULLS_REVIEW_GITHUB_TOKEN, PULLS_REVIEW_PROVIDER, PULLS_REVIEW_API_KEY, PULLS_REVIEW_MODEL, PULLS_REVIEW_BASE_URL and PULLS_REVIEW_LOCALE, and the --help flag on the CLI lists everything.

The double set of names is not redundant. The plain names are the natural ones for a shell command, and the prefixed ones matter in CI environments where GITHUB_TOKEN is already set by the runner for a different purpose.

Cost control comes from one analysis per pull request

The economics of the CI mode is the reason to use it, and the documentation states it plainly. Instead of each reviewer spending their own model key, a workflow analyzes every pull request once and posts the result as a comment.

For a team where every reviewer is running their own model over the same diff, that is the difference between a per-reviewer cost and a per-pull-request cost, and on a busy repository with long pull requests the difference is not small.

There is a second saving built into the trigger behaviour. Re-runs on an unchanged pull request skip the model call, so a workflow that runs on every push does not pay for a re-analysis of a diff that has not changed. The synchronize trigger is what fires on new commits, and the re-run guard is what stops that from being a repeated charge.

The site itself has the same idea in a different form. The hosted app at pulls.review asks you to connect your GitHub account and then you review pull requests directly in your browser, and the core package that does the diff work runs in the browser, so the fetching and grouping happen where you are reading.

A young project with a large and careful toolchain

The repository is a good example of a modern TypeScript monorepo, and the surrounding tooling says something about the effort behind it.

The root package is private, named @pulls.review/monorepo, with the version 0.3.4 tracking the release. The scripts are workspace wide: the build runs the build in each package, the dev script filters to the app package, the typecheck runs everywhere, the test is a single vitest run, and the release uses bumpp with the recursive flag.

Two of the dev dependencies are worth a mention. eslint-plugin-slop is not a common plugin, and its presence suggests an explicit effort to keep certain kinds of generated or low quality code out of the diff. The @antfu/skills package and the skills tooling, together with the skills experimental_sync prepare script and skills-lock.json, indicate that the project ships agent skills as part of its dependency graph.

The repository also carries an AGENTS.md and a CLAUDE.md, a .agents directory, a .claude directory, a plans directory, an .env.example with GITHUB_TOKEN and AI_GATEWAY_API_KEY for local testing, a vercel.json for the deployment, and x18n.config.ts with an i18n:check script for translation checking. The internationalisation setup is unusual to see in a project this young.

The licence is MIT, the primary language is TypeScript, and the last push was on 2026-10-20, the same day as the newest tag.

Editorial conclusion

Adopt pulls.review if you review a lot of pull requests and want the diff grouped by scope and summarised before you read a single line, and you are willing to connect a GitHub account to a hosted service or run the CLI yourself. Do not adopt it as a required part of a merge process while the project itself says it is heavily work in progress. Before you wire the CI action into a repository, check three things: which model provider and key you are passing, since the provider is inferred from the key and the action is a thin wrapper around a CLI that needs both a GitHub token and a model key, whether pull_request_target is acceptable in your repository, and that you understand the re-run behaviour, since a re-run on an unchanged pull request skips the model call.

Frequently asked questions

Official sources

1. antfu/pulls.review on GitHub
2. License: MIT
3. Project website
4. README
5. Releases