What the agent does
The run checks out the pull request's branch and diffs it against the base, then sorts the changed files by what kind of SvelteKit code they are. In a pnpm workspace like sveltejs/svelte.dev, the app lives in apps/svelte.dev, and a change to the docs routes touches files such as src/routes/docs/[topic]/[...path=documentation]/+page.server.js, +layout.server.ts or the param matcher in src/params/documentation.js, while a playground change touches src/routes/(authed)/playground/[...id]/+page.server.ts, gzip.js or the create.json/+server.js endpoint. Shared helpers sit under src/lib.
It reads how the repository already tests, so the new files fit in. The root package.json pins pnpm@11.5.3 and runs pnpm -r test; in apps/svelte.dev the test script is node scripts/get_svelte_template.js && vitest run, and Vitest comes from the workspace catalog at ^4.1.8. The existing tests are plain *.test.ts files beside the code they cover, such as src/lib/playground-download.test.ts, importing describe, test and expect from vitest with no global setup. So the agent writes *.test.ts files next to the changed modules in the same style.
Server code gets tested by calling it directly. For a load function or a +server.js handler the agent imports it and calls it with a hand-built event (the params, a URL and a fetch that serves fixture data), then asserts on the returned data or the Response, including the error(404) that SvelteKit throws for an unknown docs path. Pure helpers such as the match() param matcher, which refuses paths ending in llms.txt and llms-small.txt, get table tests with test.each. Svelte components only get tests when the diff changes their logic, since the repository has no component testing setup and adding one is out of scope.
It runs the app's own script, pnpm --filter svelte.dev test, so the template download that vitest run depends on happens first, and repeats until the new tests pass. It runs pnpm prettier --write on the files it adds, as the repository's AGENTS.md asks, and changes nothing outside test files.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "This pull request changes the docs and playground routes in apps/svelte.dev. Read the diff against the base branch, find the new or changed behavior that no test covers, and write Vitest tests for it as *.test.ts files next to the changed modules, in the style of src/lib/playground-download.test.ts. Test load functions and +server handlers by calling them with a constructed event, and cover their error branches. Run them with the app's test script (pnpm --filter svelte.dev test, which runs vitest run) until they pass, and format the new files with prettier. Do not change application code. Push the tests to this pull request's branch and comment on the pull request listing each test and what it covers.",
"resources": [
{
"url": "https://github.com/your-org/your-app/pull/123"
}
]
}- 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
The pull request's branch receives one commit containing only new or extended *.test.ts files, for example src/params/documentation.test.ts or a test beside the playground's +page.server.ts, plus fixture JSON under a testdata folder when a load needs content to read. No dependency is added: Vitest is already in the workspace catalog. The push triggers the repository's own ci.yml workflow, whose Lint job runs pnpm check and pnpm lint on the new files. That workflow's test job is commented out, so the vitest run in the sandbox is where the tests are shown passing, and the comment says so.
The agent's comment on the pull request names each test, the file and branch of code it covers and the input it uses ("match refuses docs/svelte/llms-small.txt"), and lists anything in the diff it chose not to test, such as markup-only changes to a .svelte file. The session's record keeps each vitest run with its output, so a reviewer can see the failure that preceded each fix.
Before merging, check that the hand-built event objects carry the fields the real code reads, that fixtures are small and committed rather than fetched, and that no test depends on network access, since the playground code talks to Supabase and the tests should not.
Run it on every pull request opened
Set up an automation with a GitHub trigger on pull_request.opened and this prompt, scoped to the repository's Project. Every pull request a maintainer or collaborator opens starts one run against its branch; fork pull requests do not trigger it, which keeps outside contributions from spending your runs. Use the automation's limit on runs per hour to cap how many start during a busy release week.
To trigger it from GitHub Actions instead, add a workflow on pull_request that calls POST /o/{org}/sessions with this body and the pull request's URL in resources, using an API key stored as an Actions secret. Set an Idempotency-Key from the pull request number and head commit so a re-run of the workflow returns the same session rather than starting another.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
A SvelteKit monorepo with a pnpm 11 packageManager pin, engineStrict and minimumReleaseAge in pnpm-workspace.yaml is exactly the setup that makes testing someone else's branch locally slow: a reinstall, a svelte-kit sync, and a script that downloads the Svelte template before Vitest runs. On Rush that happens in the run's own sandbox, on the pull request's branch, while your editor stays on yours.
What comes back can be checked line by line: a commit of test files, the vitest run output in the session's record, and the repository's CI on the push. Pull requests opened at the same time are covered at the same time, each in its own sandbox, so tests arrive with the change rather than in a separate cleanup pull request weeks later.
Frequently asked questions
Does it use npx vitest run or pnpm?
It uses the command your repository uses. In a pnpm workspace it runs the app's test script through pnpm --filter, because that script may do setup first, as svelte.dev's downloads a template before vitest run. In a single-package npm project, npx vitest run is the same thing.
Will it add @testing-library/svelte or Playwright?
Not unless you ask. It writes tests for the code the pull request changes with the tools already installed, and for most route changes that means calling load functions and handlers directly. If a change can only be tested through a rendered component or a browser, the comment says so.
How does it test a load function that calls fetch?
It passes a fetch in the test's event that answers from a small fixture, the same fetch argument SvelteKit gives the function at runtime. That keeps the test offline and exercises the real load code, not a stubbed copy of it.
What happens when the author pushes again?
With only pull_request.opened on the trigger, nothing; the tests already pushed stay. Add pull_request.synchronize to have each push reviewed for new untested code; the agent then extends its own test files rather than duplicating them.