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 with this body:
{
"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"
}
]
}- 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.
- 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.
- 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.
The use case this job follows, with its automation and trigger: Review every pull request.
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.