What the agent does
The agent starts from what the repository declares rather than from an Angular template. In the Angular RealWorld app (realworld-apps/angular-realworld-example-app) it reads package.json and finds the @angular packages pinned to 21.2.12, TypeScript at ~5.9.3, and a test script that runs vitest, with the Playwright test:e2e scripts listed separately. It notes engines asking for Node >=20.11.1 and a bun.lock lockfile next to the package, and it installs dependencies with the package manager the prompt names.
It checks out the pull request branch and runs npm test, which starts Vitest. vitest.config.ts sets the jsdom environment, points at a setup file at src/test-setup.ts, and includes only src/**/*.spec.ts, so the suite runs the colocated specs, such as the articles.service.spec.ts beside src/app/features/article/services/articles.service.ts, in jsdom rather than a browser. The coverage provider is v8, and the repository's test:coverage script already knows how to report it.
While the suite runs, the agent reads the diff with the surrounding code, not just the changed lines. The article feature keeps its HTTP calls in src/app/features/article/services/articles.service.ts, comments.service.ts and tags.service.ts, and auth state in src/app/core/auth, so a change to an article or auth service is checked against the components, resolvers and models in src/app/core/models that consume it.
The review it posts is one GitHub review per run: a summary that quotes the npm test result, separates blocking issues from suggestions, and inline comments that cite file and line for each finding. It never pushes commits; the prompt forbids it and the run carries no changes back to the branch.
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 npm, run `npm test`, and read the diff with the surrounding code in the article and auth services. Post one GitHub review that cites file and line for every finding, separates blocking issues from suggestions, and includes the test result. 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. The summary quotes the Vitest result, names each finding with its file and line, and marks which findings block merge and which are suggestions. Inline comments sit on the lines they cite, so a reviewer opens the conversation tab and sees each point in place rather than in a detached list.
The session's trajectory keeps the record behind the review: the install command, the npm test run with Vitest's per-file output, and the files the agent read while checking the diff against its surroundings. A reviewer who doubts a finding can trace exactly how the agent reached it before deciding.
Before trusting the review, a reviewer checks that each blocking finding reproduces: check out the branch, run npm test, open the cited line. Suggestions are labelled and can be dismissed without holding the merge.
Run it on every pull request opened
Create an automation with a GitHub trigger on pull_request.opened and pull_request.synchronize, scoped to the base branches you protect with a branch pattern, and give it this prompt. Every pull request then gets its own run in its own sandbox, and the review lands minutes after the push instead of waiting for a free teammate.
Set a webhook URL on the API key and Rush POSTs run.completed when each run's turn finishes, with the session URL, so your server can post the review link where the team watches pull requests. A key runs at most max_concurrent sessions at once, 4 by default, and answers 429 past it, so raise the limit on the key when a busy week opens many pull requests.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
Reviewing a pull request on a laptop means stashing your own work, checking out someone else's branch, installing dependencies and waiting for the suite before you can say anything. On Rush the agent does that in its own sandbox: it checks out the pull request, runs npm test there, and keeps every command and its output in the trajectory, so the review is backed by an executed Vitest suite rather than a diff read.
One run per pull request also means many pull requests at once. Ten open pull requests get ten sandboxes, each posting its own review, none of them queued behind a colleague. The author keeps working because nothing runs on their machine, and the result is checkable: a review with the test result in it, next to the full record of how it was produced.
Frequently asked questions
Does it use our own test setup?
Yes. It runs the repository's test script, which is Vitest here, with the configuration in vitest.config.ts (jsdom, src/**/*.spec.ts). It does not substitute its own runner or skip the suite, and the review quotes the result.
Will it push fixes to the branch?
No. The prompt says not to push commits, and a review run writes only the review on the pull request. If you want the defect fixed, send a follow-up message to the same session or start a new run with a fix prompt.
What if the suite fails for a reason unrelated to the diff?
The review quotes the failing spec files and still posts the findings it has. Findings and suite state are listed separately, so a flaky or pre-existing failure does not masquerade as a defect introduced by the change.
Does it also run the Playwright end-to-end scripts?
The test script runs only the Vitest specs. The repository also has test:e2e scripts that call Playwright; name them in the prompt if you want them run, knowing they need browsers and a served app.