What the agent does
The agent reads how the app is built before it chooses how to test it. In sveltejs/realworld, package.json pins @sveltejs/kit ^2.52, Svelte 5 with runes: true in svelte.config.js, Vite 7 and packageManager: pnpm@10.20.0, and its only checks are prettier --check. There is no test directory, no test runner and no Playwright dependency. The adapter is @sveltejs/adapter-vercel, so the agent tests against vite dev (port 5173) rather than a production build that expects Vercel's runtime.
Most of this app's behavior is server-side, which is what makes browser tests worth having here. Registration posts to the default action in src/routes/register/+page.server.js, which calls the RealWorld API through src/lib/api.js and stores the user as a base64 jwt cookie that hooks.server.js decodes on every request. Writing an article posts to src/routes/editor/+page.server.js and redirects 303 to /article/<slug>. Following an author is the toggleFollow action on /profile/@<user>, sent from a form with a hidden following checkbox and progressive enhancement that disables the button while it runs.
The specs drive those forms the way a person would. The registration spec fills Your Name, Email and Password, clicks Sign up, checks the redirect to / and that the nav shows the new username, and checks that registering the same name again shows the API's error list. The article spec signs in, fills Article Title, What's this article about?, the markdown body and Enter tags, clicks Publish Article, and checks the article page renders the sanitized markdown and tags. The follow spec has a second user open the first user's profile, follow, reload, and see the button state persist, then unfollow.
Every request goes to https://api.realworld.show/api, the base constant in api.js, so the agent creates unique users per run to stay clear of other data on that shared backend. It runs the suite headless several times. Where a test exposes the app rather than the test, it stays in the suite as test.fail() with the cause written down; registration failures returning fail(401, ...) rather than a validation status is one behavior the agent checks and reports.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Write Playwright end-to-end tests for registration, writing an article and following an author in this SvelteKit app. Put them in e2e/ with a playwright.config that starts the dev server, run them headless, and open a pull request with the passing suite. If a test exposes a real bug, mark it expected to fail and explain it in the description.",
"resources": [
{
"url": "https://github.com/your-org/your-sveltekit-app"
}
]
}- 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 pull request that adds e2e/register.spec.ts, e2e/article.spec.ts and e2e/follow.spec.ts, a fixture that registers a unique user through the real form, and a playwright.config.ts whose webServer runs pnpm dev and waits on port 5173. @playwright/test and a test:e2e script go into package.json and pnpm-lock.yaml; nothing under src/ changes.
The description lists each spec and the form action it proves, how to run the suite locally, and every test marked test.fail() with the file and line behind it. The session's trajectory keeps the browser install and every npx playwright test run with its full output.
Before merging, a reviewer checks whether the specs should keep using the public RealWorld API or a backend the team runs, whether the follow spec's two users fit how the team seeds test data, and which expected failures to fix first. A follow-up on the same session can add a GitHub Actions job for the suite.
Run it on every Svelte or SvelteKit upgrade
When Dependabot or Renovate opens a pull request that bumps svelte or @sveltejs/kit, a GitHub webhook can send a request with that pull request in resources, asking the agent to run the e2e suite on it and fix any spec the upgrade broke. Form actions and progressive enhancement are what framework upgrades change, so this is where the suite pays off.
Set a webhook URL on the API key and Rush POSTs run.completed or run.failed when the turn finishes, so your server can comment the result on the upgrade pull request before anyone merges it.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
SvelteKit's form actions only show their real behavior with a server, cookies and a browser together, which on a laptop means a dev server, a Chromium install and a test loop that takes over your terminal. In its own sandbox the agent starts vite dev, installs Chromium and runs the specs headless, repeatedly, without touching your machine.
The result is checkable: every Playwright run is in the trajectory with its output, and expected failures are named in the pull request instead of quietly skipped. Because each run is isolated, the same request can cover several SvelteKit apps at once without their dev servers competing for port 5173.
Frequently asked questions
Why test against vite dev and not a production build?
This app builds with @sveltejs/adapter-vercel, whose output expects Vercel's runtime. vite dev runs the same server load functions and actions locally. If your app uses adapter-node, ask for vite build and vite preview in the prompt and the agent tests the built app instead.
Do the tests work with JavaScript disabled?
They run with JavaScript on by default, which exercises use:enhance. Because SvelteKit forms work without it, you can ask for a second Playwright project with javaScriptEnabled: false, and the agent runs every spec both ways.
Does it need pnpm?
It uses the package manager the repository declares. This app sets packageManager: pnpm@10.20.0, so the agent uses that version. A repository with package-lock.json or bun.lock gets the matching tool.
Will it write unit tests too?
Not in this request, which is about the browser. Unit tests for load functions and form actions are a separate job with Vitest, and a follow-up on the same session can add them beside the e2e suite.