What the agent does
The agent reads the pull request's diff and finds the server routes it changes. In a Nuxt app like nuxt-ui-templates/dashboard those are the files in server/api/: customers.ts, mails.ts, members.ts and notifications.ts, each a defineEventHandler imported from nuxt/server that Nuxt serves at /api/customers, /api/mails and so on. In the template each handler returns a typed array, such as User[] from ~/types for customers or notifications with dates built from date-fns sub(). A pull request that adds a query filter, pagination, a new field or a new route is the behavior the agent writes tests for.
It finds that the dashboard template has no tests and no test runner. package.json has build, dev, preview, lint and typecheck scripts, and .github/workflows/ci.yml runs lint and typecheck on Node 24 with pnpm. So the first run on a repository like this adds what Nuxt documents for testing: vitest and @nuxt/test-utils as dev dependencies, installed with the pnpm version packageManager names, a vitest.config.ts, and a test script. It lists these additions in its comment so the team can decide to keep them.
The tests use @nuxt/test-utils/e2e: setup() builds the app once per file and $fetch('/api/customers') calls the real route on it, so a test exercises the handler, its nuxt/server import and the ~/types alias exactly as Nuxt serves them, with no hand-built event object. Each test checks one behavior the pull request added: the filtered list for a status query, an empty list for no match, the fields every customer row carries, or notifications sorted newest first when the diff added sorting. Dates are compared relative to the time the test ran, since the template builds them from the current time.
It runs npx vitest run until the new tests pass, then pnpm run lint and pnpm run typecheck, because the repository's CI already runs those two and a new test file must pass them too. A test that fails because the route returns the wrong data stays out of the commit, as the prompt asks, and the agent explains it in its comment.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "This pull request changes the server API routes. Read the diff against the base branch and list the new or changed behavior in server/api that no existing test covers. If the repository has no test runner, add vitest and @nuxt/test-utils with pnpm, a vitest.config.ts and a test script, and say so in your comment. Write Vitest tests that build the app with setup() from @nuxt/test-utils/e2e and call each route with $fetch, one test per behavior the pull request adds, comparing generated dates relative to now. Run npx vitest run until the new tests pass, then pnpm run lint and pnpm run typecheck. Do not change application code: if a test fails because the code is wrong, leave it out and describe the failure. Push the tests to this pull request's branch and post a comment listing each test and the behavior 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
What comes back is a commit on the pull request's branch with test files under a test/ directory, such as test/api/customers.test.ts, and on a repository with no runner yet, vitest.config.ts, the test script and the new dev dependencies in package.json and pnpm-lock.yaml. Nothing under server/, app/ or nuxt.config.ts changes, so the pull request's own diff stays what its author wrote.
The agent's comment on the pull request lists each test with the route and behavior it checks, names the setup it added, and shows the commands it ran, including lint and typecheck. When a test exposed a defect, such as a filter that ignores its query parameter, the comment shows the $fetch call, what came back and the handler line responsible. The repository's CI then lints and typechecks the pushed commit; add pnpm test to it to run the new tests there too.
Before merging, a reviewer checks that tests assert behavior a page relies on rather than the exact sample rows in the template, which a real app replaces with a database, and that the new dev dependencies match the Nuxt major the app uses.
Run it on every pull request opened
Add an automation with this prompt to the Project connected to the Nuxt repository and give it a GitHub trigger on pull_request.opened. Every pull request opened by someone with write access starts a run whose prompt names the pull request number, URL, title, author and base branch. Forked pull requests never fire it. Once the first run has added the runner, later runs reuse it and only add tests for their own pull request.
If you start runs from your own server, receive GitHub's pull_request webhook and send this request on opened with the pull request's URL in resources, so Rush clones that branch. A key runs at most 4 sessions at once by default and answers 429 past that, so retry with backoff when many pull requests open together.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Testing Nuxt server routes for real means building the app, which takes time and a full node_modules, and doing that on your laptop for each pull request means switching branches under your running nuxt dev. On Rush each run builds the app in its own sandbox at the pull request's branch with the pnpm version the repository pins, so your dev server keeps running and several pull requests are tested at once.
The result carries its own evidence. The trajectory keeps each install, vitest run, lint and typecheck command with its output, and the comment separates the tests from the setup it had to add. Tests arrive with the change they cover, so the server routes gain coverage one pull request at a time instead of in a cleanup that never gets scheduled.
Frequently asked questions
Does it test Vue components and pages too?
This prompt covers the server routes in server/api/. @nuxt/test-utils can also mount components in a Nuxt environment, so ask for component tests in the prompt when a pull request changes the dashboard's pages or composables.
Why build the whole app instead of calling the handler directly?
The handlers import defineEventHandler from nuxt/server and types through the ~/ alias, which only resolve inside a Nuxt build. Building once per test file with setup() tests the route the way the browser reaches it, without a fake event object that could drift from Nuxt's.
Will it touch my CI workflow?
No. The prompt keeps the commit to tests and the runner they need, and .github/workflows/ci.yml is left as it is. The comment suggests adding pnpm test after the lint and typecheck steps.
What if the pull request only changes UI?
Then nothing in server/api/ changed, and the agent says so in a comment and pushes nothing. It does not invent server tests for a pull request that only moves components around.