# Review Pull Requests Automatically in a SvelteKit App

Yes. An agent checks out the SvelteKit pull request, runs npx vitest run, and posts one review of the article and profile routes with that output.

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

## What the agent does

The agent checks out the pull request and reads the toolchain before it believes the test command. In an app shaped like sveltejs/realworld, package.json is named realworld.svelte.dev, packageManager is pnpm@10.20.0, and pnpm-lock.yaml is the lockfile. .nvmrc says 20. Dependencies include @sveltejs/kit ^2.52.2, svelte ^5.55.7, vite ^7.3.2 and @sveltejs/adapter-vercel ^6.3.2. Scripts are dev, build, preview, lint as prettier --check ., and format as prettier --write .. There is no test script, no Vitest dependency, and no vitest config. The agent still runs npx vitest run, because that is the request, and the review quotes the failure to find a suite. It does not add Vitest to produce a pass, and it does not push.

Article routes are the first half of the read. src/routes/article/[slug]/+page.server.js exports load, which Promise.alls api.get of articles/${params.slug} and the comments endpoint, runs the body through marked, then sanitizeHtml, and returns { article, comments }. Actions are createComment, deleteComment, deleteArticle and toggleFavorite. Each of the first three calls error(401) when locals.user is missing. deleteArticle calls redirect(307, '/') after the delete. toggleFavorite reads a favorited checkbox, posts or deletes the favorite endpoint, and redirects to the Referer or back to the article. It does not await the api.post and api.del calls. src/routes/article/[slug]/+page.svelte, Comment.svelte and CommentInput.svelte are the view.

Profile routes are the other half. src/routes/profile/@[user]/+page.server.js loads articles through get_articles(event, 'author') from get_articles.js. The favorites folder has its own +page.server.js. Actions on the profile page include toggleFollow, which error(401)s without locals.user, posts or deletes profiles/${params.user}/follow, and returns fail(422, result) when the API answers errors. src/lib/api.js is the client those loads call. src/lib/ArticleList/index.svelte and ArticlePreview.svelte render the lists both routes return. A diff that changes the author argument, the 401 check, or the un-awaited favorite call is what the review cites, at that line.

One GitHub review carries the vitest output, then findings split into blocking and suggestions. Blocking is a load or action change that drops the 401, returns unsanitized HTML, or redirects to the wrong path. A suggestion is the missing test runner, or that lint in this repo is prettier --check and was not the command the request asked for. The agent installs with pnpm because packageManager says so. It can run pnpm run lint only when you add it to the input. The default review does not pretend prettier ran.

## Start it with one API call

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

```json
{
  "agent": "claude",
  "input": "Review this pull request on the SvelteKit RealWorld app. Check it out, install with pnpm (packageManager pnpm@10.20.0, .nvmrc 20), and run npx vitest run. If Vitest is not a dependency, quote that result and do not add it. Read the diff with src/routes/article/[slug]/+page.server.js, src/routes/profile/@[user]/+page.server.js, src/routes/profile/@[user]/get_articles.js and src/lib/api.js. 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"
    }
  ]
}
```

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. The session read names the repository and the pull request. The test section is the npx vitest run output, which on this repository is the absence of a suite, not a count of passed files. Findings cite lines in the article load, the profile follow action, or get_articles.js when the diff edits them. The favorite action's missing await is cited only when the diff touches toggleFavorite or when the surrounding read is needed to explain a change next to it. The branch gains no commit from the agent.

A reviewer checks that the review did not invent a Vitest config, and that a 401 or a redirect is tied to a line in +page.server.js. The transcript keeps the pnpm install and the vitest invocation. Follow GET /o/{org}/sessions/{id}/events while the turn runs. When it finishes, result on the session is the answer, and the run.completed webhook repeats it up to 16 KiB. A follow-up can ask for prettier --check on the same parked checkout without cloning again.

## Run it on every pull request opened

On pull_request.opened, POST this session with the pull request URL in resources so the sandbox checks out that head. The Rush GitHub App has to be installed on the repo. Use the delivery id as Idempotency-Key. A second delivery with the same key and the same body returns the same session. A new commit on the pull request needs a new key if you want another review rather than the parked one.

The key webhook tells you the turn finished. type is run.completed, run.failed or run.cancelled. Answer 2xx within 5 seconds or Rush retries at 2, 4 and 6 minutes with the same webhook-id. SvelteKit installs are smaller than a mobile build, but max_concurrent still defaults to 4 and a fifth start is 429. Queue the extra pull requests.

## Why run it on Rush?

This repository's lint script is Prettier, and it has no test runner, which is easy to miss if you only read the diff of a +page.server.js. Running the requested vitest command in a sandbox records that fact next to the pnpm version and the Node version in .nvmrc. You do not switch your local checkout onto the pull request, and you do not install pnpm 10.20.0 to find out the suite is missing.

The review earns its keep in the actions: which ones call error(401), which redirect, and which fire a request without await. Those are line citations a teammate can open. The transcript is the proof the command ran. Several article or profile pull requests review at once, each sandbox with its own node_modules, and the GitHub review is the artifact the author replies to.

## Frequently asked questions

### There is no Vitest. Should I change the request to pnpm run lint?

You can. lint is prettier --check .. The published request still runs npx vitest run so the review records the missing suite instead of silently substituting Prettier. If you switch the command, say so in the input, and the review should quote prettier rather than claim tests ran.

### Will it rewrite the article load to await the favorite call?

It will not push that change. toggleFavorite calls api.post or api.del without await and then redirects. If the diff touches that action, the review cites the line. A fix is a separate session whose input asks for a commit, or a follow-up that you explicitly allow to push.

### Does the review run the app in a browser?

Not by default. The request is a checkout, an install, vitest, and a read of the server files. The sandbox has a browser, and a follow-up can ask it to open the dev server, but this review does not start vite dev or take screenshots unless the input says to.

### The profile route is named @[user]. Does that break the checkout?

No. That is the directory src/routes/profile/@[user], which SvelteKit uses as the param. The agent reads +page.server.js and get_articles.js inside it. A finding cites that path. The @ is not a Git revision.

### Can it review the editor routes in the same run?

Yes. Add src/routes/editor/+page.server.js and src/routes/editor/[slug]/+page.server.js to the input. The same session still has one repository. Keep the vitest line so the missing runner is reported once for the whole pull request.