How to review every pull request as commits land

Human review arrives in a batch, late, after the author has moved on. An agent can read each push as it lands instead. The risk is noise: a naive bot re-reviews the entire diff on every commit, and the team mutes it within a week.

The code_review surface is built for this. It reviews only the commits it has not seen yet, and it never re-comments a line it already reviewed.

ellipsis:
  version: v1
  name: Code reviewer
  description: Reviews the new commits on every pull request as they land

claude:
  model: claude-haiku-4-5-20251001
  system: |
    Review only the new, unreviewed commits on this pull request.
    Look for correctness and logic bugs, unhandled edge cases, missing
    authorization checks, and regressions to public behavior. Leave
    concise inline comments on the exact lines, and suggest the fix
    rather than describing the problem in the abstract. Skip pure
    style and naming; a linter handles those. If the change looks
    correct and low-risk, say so briefly instead of inventing nitpicks.

trigger:
  type: react
  code_review:
    repositories: [splitshift-web, splitshift-api]
    for:
      users: true
      bots: false

budget:
  session: 0.30
  day: 3.00

When priya-shah opens "Expire pending trades on account deactivation" and pushes three more commits over the afternoon, the agent reviews four times, each time seeing only what that push added. The third push drops a rest-period check and the comment lands on that line, with no repetition of the first review.

Two lines keep the volume sane. for.bots: false is the default, so Dependabot pull requests never trigger a review. A small model is the right default here: review runs on every push across every repository, so it is the highest-frequency agent most teams deploy.

For a deployable version, use the Code Reviewer template. To review one narrow class of change more carefully, see How to review database migrations before they merge.

Surfaces

A react trigger sets exactly one surface block, and each config is one automation. Two surfaces cover the pull request lifecycle: pull_request reacts to the actions you list, and code_review follows the head as a review bot. Every surface carries only the filters that make sense for it.

React fires every matching config independently, so a reviewer, a describer, and a labeler can all run on the same pull request.

Actions do not each start a session. Everything an agent reacts to on one pull request is delivered into one durable conversation: the first action starts it, later ones continue it with full memory of what the agent already did, and a merge or close ends it. A react agent posts no reply per action; it acts through the sandbox.

pull_request

on lists the pull request actions to react to:

Filters: repositories (the repos to watch, by name), base and head (branch names, prefixes ending in *, or default), draft (true or false), labels (any match), paths (changed-file globs, ** allowed), and for (see Who triggers it).

trigger:
  type: react
  pull_request:
    on: [pushed]
    base: [main]
    paths: ["src/api/**"]

code_review

code_review reviews the unreviewed part of a pull request on every head advance, and never re-comments lines it already reviewed. It is action-less: it fires when the head advances (open plus each push) and there are new commits past what the agent last reviewed. Use it for a review bot; use pull_request: {on: [pushed]} when you want to run something on each push (tests, a description update).

It reuses the pull_request filters minus on: repositories, base, head, draft, labels, paths, for.

trigger:
  type: react
  code_review:
    base: [main]
    for: { users: true, exclude_users: [priya-shah] }

Scoping to a repository

repositories is the watch set: a list of repository names to react in. Owners default to the account. An empty list watches every repository. This is independent of sandbox.repositories — the repository that triggered the event is always cloned into the sandbox.

trigger:
  type: react
  pull_request:
    on: [opened]
    repositories: [splitshift-api]

Who triggers it

for decides which authors trigger a config, classified on the pull request author. It is include minus exclude:

• users — true (all humans), a list of logins, or false/[] (none). Defaults to true.
• bots — same shape, for bot accounts. Defaults to false, so automation like Dependabot never triggers by accident.
• exclude_users / exclude_bots — logins to subtract from the include set.

Because react fires every matching config, for is how you make two configs mutually exclusive: a general reviewer for: { users: true, exclude_users: [priya-shah] } and a per-author reviewer for: { users: [priya-shah] } never both fire on one pull request.

Next

Keep descriptions current on the same pushes with How to keep pull request descriptions up to date, answer conversational requests instead of events with How to answer codebase questions from GitHub, Slack, and Linear, or see how a session executes for what happens after the trigger fires.