# Review Pull Requests Automatically in a Next.js App

Yes. The agent checks out the pull request, runs pnpm prettier:check, tsc and next build in its own sandbox, and posts one review citing file and line.

[Run this on Rush](https://cloud.getrush.ai/run/review-pull-requests/nextjs/), in a Project that has your repository.

## What the agent does

The agent starts from what the repository declares. In vercel/commerce, `package.json` pins `next` at 15.6.0-canary.60, `react` and `react-dom` at 19.0.0 and `typescript` at 5.8.2, and the only lockfile is `pnpm-lock.yaml`, so the install is `pnpm install`. There is no Vitest, Jest or Playwright: the `test` script is `pnpm prettier:check`, and no test file exists anywhere in the tree. The checks the agent can run are the ones the repository has: `pnpm prettier:check`, `pnpm exec tsc --noEmit` against a `tsconfig.json` with `strict` and `noUncheckedIndexedAccess` on, and `pnpm build`, which is `next build`.

The cart is where a review earns its keep. `components/cart/actions.ts` opens with `"use server"` and exports `addItem`, `removeItem`, `updateItemQuantity`, `redirectToCheckout` and `createCartAndSetCookie`. Each one calls the Shopify client in `lib/shopify/index.ts`, where `getCart` is marked `"use cache: private"`, tags its result with `TAGS.cart`, gives it a `cacheLife` of seconds and reads the `cartId` cookie, and each action ends with `updateTag(TAGS.cart)` so the next read sees the change. The agent reads the diff together with these two files and `components/cart/cart-context.tsx`, whose `useOptimistic` reducer applies `ADD_ITEM` and `UPDATE_ITEM` before the server answers.

Findings in this code are about the gaps between the three layers: an action that mutates the cart but no longer calls `updateTag`, so the cached `getCart` keeps serving the old lines; a reducer branch that computes a quantity the server action never receives; an error path that swallows the Shopify response and returns the generic string the user sees as a toast; a new fetch in a server component without the cache tag that the revalidation route in `app/api/revalidate/route.ts` relies on. Each finding cites the file and line and says whether it blocks merge.

`next.config.ts` turns on `experimental.ppr`, `inlineCss` and `useCache`, and `.env.example` lists the five variables the app reads, `SHOPIFY_STORE_DOMAIN` and `SHOPIFY_STOREFRONT_ACCESS_TOKEN` among them. The agent copies the example file so `next build` has every name it expects; where a step needs a live store to complete, the review says so instead of guessing at the result. One review comes back per run, and the prompt forbids pushing commits.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Review this pull request. Check it out, install dependencies with pnpm, then run `pnpm prettier:check`, `pnpm exec tsc --noEmit` and `pnpm build`. Read the diff with the surrounding code in the cart server actions, the Shopify client and the cart context, paying attention to cache tags, the optimistic reducer and error handling. Post one GitHub review that cites file and line for every finding, separates blocking issues from suggestions, and quotes the result of each command. Do not push commits.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app/pull/42"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a review on the pull request. Its summary quotes the three commands with their output: Prettier's list of unformatted files if any, the TypeScript errors with file and line if any, and whether `next build` completed in the sandbox. Below that the findings are listed with file and line, blocking ones first, suggestions after.

Inline comments sit on the cited lines, so a note about a missing `updateTag` call sits on the action that needs it. The session's transcript keeps every command the agent ran and every file it opened, so a reviewer can see that the finding about `getCart` came from reading `lib/shopify/index.ts`, not from the diff alone.

Before merging, a reviewer runs the same three commands on the branch and checks each cited line against its comment. A suggestion can be dismissed without holding the merge; a blocking finding about cache invalidation deserves a manual pass through the cart in a preview deployment.

## Run it on every pull request opened

Create an automation with a GitHub trigger on `pull_request.opened` and `pull_request.synchronize`, with `branch_patterns` set to the branch the storefront deploys from, and this prompt. Every pull request then gets its own run in its own sandbox, and a push to the branch gets a fresh review of the new diff. Pull requests from forks never fire the trigger, so outside contributions still wait for a maintainer.

Set a webhook URL on the API key and Rush POSTs `run.completed` when each run finishes, with the session URL. Your server can post the review link into the channel that watches the storefront. A key runs at most `max_concurrent` sessions at once, 4 by default, and answers `429` past that, so raise the limit before a week with many open pull requests.

## Why run it on Rush?

Reviewing a Next.js storefront on a laptop means checking out the branch, running `pnpm install` against a lockfile that changes often, and waiting for `next build` before the first comment can be written. On Rush the agent does that in its own sandbox and keeps every command's output, so the review can say whether the build passed rather than whether the diff looks right.

The cart code in this template spans a server action, a cached fetch and a client reducer, and a mistake in one layer shows up only when the others run. A reviewer that executes the code sees the TypeScript error the diff hides, and several pull requests get reviewed in parallel, each in its own sandbox, while the author's working tree stays untouched.

## Frequently asked questions

### There are no tests in this repository. What does the review check?

Prettier, the TypeScript compiler and the production build, which are the checks the repository defines. The review says that no test suite exists rather than inventing a result. If the pull request adds Vitest or Playwright, the agent runs that too and quotes it.

### Does the build need my Shopify credentials?

The app reads `SHOPIFY_STORE_DOMAIN`, `SHOPIFY_STOREFRONT_ACCESS_TOKEN` and `SHOPIFY_REVALIDATION_SECRET` from the environment. The agent copies `.env.example` so the names resolve, and a step that needs a live store is reported as such. To build against your store, start the session in a Project and save the values as secrets there; the agent reads them as environment variables.

### Will it run on pull requests from forks?

No. A GitHub trigger fires only for work by an owner, member or collaborator, and pull requests from forks never fire it. Start a run by hand with the pull request URL as the resource when a fork contribution needs a review.

### Does it push fixes to the branch?

No. The prompt forbids it, and the review only comments. If you want a fix, send a follow-up to the same session with `POST /o/{org}/sessions/{id}/messages` asking it to apply one named finding and open a separate pull request.