What the agent does
The agent checks out the pull request and reads the toolchain before it trusts the test command in the request. In a Nuxt app shaped like nuxt-ui-templates/dashboard, package.json is named nuxt-ui-template-dashboard, packageManager is pnpm@12.11.2, and pnpm-lock.yaml is lockfileVersion 9.0 with that same pnpm version under packageManagerDependencies. Dependencies include nuxt ^4.6.1, vue ^3.5.43, typescript ^6.0.3, @nuxt/ui ^4.11.3 and @vueuse/nuxt ^14.4.0. Scripts are build, dev, preview, postinstall nuxt prepare, lint as eslint ., and typecheck as nuxt typecheck. There is no test script, no vitest dependency, and no vitest.config. .github/workflows/ci.yml runs on Node 24 with pnpm install, pnpm run lint and pnpm run typecheck.
npx vitest run is still the command the request names, so the agent runs it and keeps the output. On this tree that command does not execute a suite, because Vitest is not installed and no file under server or app matches a spec. The review says that in the test paragraph, and it quotes the CI workflow's real checks so a reader does not think the project is untested in GitHub Actions. It does not add Vitest, a spec file, or a test script in order to manufacture a green run, and it does not push.
The diff it is asked to read is the server API. server/api/members.ts, server/api/customers.ts, server/api/mails.ts and server/api/notifications.ts are Nitro routes. Each default-exports defineEventHandler from nuxt/server and returns a const array. members lists username and role, with owner on some rows and member on others. customers is a User array with status subscribed, unsubscribed or bounced. mails and notifications import sub from date-fns and stamp dates from now. notifications includes the body string abandonned cart on several rows. nuxt.config.ts sets routeRules so /api/** has cors true, and modules are @nuxt/eslint, @nuxt/ui and @vueuse/nuxt. None of the handlers read the event, check a method, or look at a session.
The review is one GitHub review. Findings cite the file and the line: a handler that returns the whole array with no auth, a cors rule that opens /api/**, a typo in the fixture copy the diff touches, or a field a component reads that the handler stopped returning. Blocking means the diff changes a response a page already fetches. A suggestion is the missing Vitest suite, or that CI never runs a test step. The agent installs with pnpm because packageManager and the lockfile say so, even though a generic npm install would ignore pnpm-lock.yaml.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Review this pull request on the Nuxt dashboard. Check it out, install with the package manager in package.json (pnpm@12.11.2), and run npx vitest run. If Vitest is not installed, say so and do not add it. Read the diff with server/api/members.ts, server/api/customers.ts, server/api/mails.ts, server/api/notifications.ts and nuxt.config.ts, and with .github/workflows/ci.yml which runs pnpm run lint and pnpm run typecheck on Node 24. Post one GitHub review that cites file and line for every finding, separates blocking issues from suggestions, and includes the vitest result. Do not push commits.",
"resources": [
{
"url": "https://github.com/your-org/your-app/pull/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.
- 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 one review on the pull request the resources URL named. The session read includes that repository and pull request. The review leads with the npx vitest run output, which on this dashboard template is the failure to find a suite, then the CI commands the repository actually runs. Findings point at lines in server/api and at the cors route rule when the diff changes them. The pull request's own files are unchanged, because the agent was told not to push.
Before treating the review as done, a reviewer checks that a red vitest line is explained as a missing tool and not as a failed assertion, and that every cited line is in the diff or in the handler the diff calls. The transcript stores the pnpm install and the vitest invocation as tool_use events with tool_result output. Follow the live stream on GET /o/{org}/sessions/{id}/events, or read the finished turn from the session. A parked sandbox keeps that checkout for a follow-up if you want the same agent to re-read one route.
Run it on every pull request opened
On pull_request.opened, your server POSTs this session with the pull request URL in resources so the sandbox clones that head. Use the GitHub delivery id as the Idempotency-Key. A retry of the same delivery returns the session already started, and the same key with a different body is 409 IDEMPOTENCY_CONFLICT. One repository per run, so each Nuxt pull request gets its own sandbox.
Point the API key's webhook at your server. The finish event is run.completed, run.failed or run.cancelled, with session_url and events_url. Answer 2xx within 5 seconds. The key's creator sets webhook_url, and the key itself cannot. When many dashboards open pull requests together, stay inside max_concurrent or the extra POST answers 429.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
A Nuxt review that only reads the diff will treat server/api/customers.ts as a backend. It is a static array behind defineEventHandler, and the template's CI never runs Vitest. Running the requested command in a sandbox makes that fact part of the review, next to pnpm's lockfile version, instead of a guess from package.json. Your laptop does not need Node 24 or pnpm 12.11.2 installed for the duration of the read.
The kept output is the point. The transcript shows that vitest was executed and what it printed, and the review cites lines in the four handlers rather than a generic note about API routes. Several pull requests review at once, each in its own sandbox, and the GitHub review is what teammates see on the pull request. The agent does not merge.
Frequently asked questions
The template has no Vitest. Does the review fail the pull request?
The review reports the command result. It does not add a failing check to GitHub Actions, and it does not push a vitest.config to make the command pass. Your branch protection is unchanged. The test paragraph tells the author that CI's real steps are pnpm run lint and pnpm run typecheck on Node 24.
Will it rewrite my server routes to add auth?
It posts a review. If a handler returns its array with no check, and the diff touches that handler, the review cites that line as a finding. The file on the branch stays as the author pushed it.
Does it install with npm or pnpm?
pnpm, because packageManager is pnpm@12.11.2 and the lockfile is pnpm-lock.yaml at lockfileVersion 9.0. The preinstall of the dashboard does not set only-allow, but the CI workflow uses pnpm/action-setup. The review says which installer ran.
What if the pull request changes a Vue page and not server/api?
resources still checks out the whole pull request. The input points the read at server/api, which is the right scope when the change is a route. Name the page file in input when the diff is a component under app/pages, and keep the same vitest line so the missing suite is still recorded.
Can a teammate ask it to look again without a new pull request?
Yes. When the session status leaves running, POST /o/{org}/sessions/{id}/messages with a new input. A message sent while the turn is running is 409 TURN_ACTIVE. The follow-up wakes the parked sandbox on the same checkout.