What the agent does
When Vercel reports a failed deployment, the event starts a run and arrives after the prompt. The agent reads the deployment's build log through the Vercel connection, picks out the error SvelteKit printed, and clones the repository at the commit Vercel built into its own cloud sandbox.
In a SvelteKit app like sveltejs/realworld, the agent reads package.json: vite build as build, pnpm@10.20.0 in packageManager with a pnpm-lock.yaml, SvelteKit 2.52, Svelte 5.55 and Vite 7. svelte.config.js uses @sveltejs/adapter-vercel and sets compilerOptions.runes to true, so every component is compiled in runes mode. Legacy syntax such as export let props or a $: statement fails the compile, which is a common cause of a red deployment after an upgrade or a copied component.
The app is small enough to read in full. Data loads in +page.server.js files under src/routes/ for articles, the editor, login, profile and settings, and every request goes through src/lib/api.js to https://api.realworld.show/api. src/hooks.server.js reads the jwt cookie into event.locals.user. The agent installs with pnpm, runs pnpm build, and confirms the sandbox fails on the same line as the Vercel log before changing anything.
It fixes the cause in the file the error names, for example rewriting a component's props with $props() for runes mode or correcting an import of a server-only module into a .svelte file, then runs pnpm build until adapter-vercel writes its output. The repository has no test suite, so it also runs pnpm lint, which is prettier --check . here, and a vite preview to load the pages the fix touched.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Vercel deployment of this SvelteKit app failed; the deployment event follows this prompt. Use the Vercel connection to read that deployment's build log and quote the failing line. Install with pnpm and the lockfile, reproduce the failure with pnpm build in the sandbox, fix the cause, confirm the build passes with adapter-vercel and pnpm lint passes, load the affected pages with vite preview, and open a pull request that quotes the failing log line and explains the fix.",
"resources": [
{
"url": "https://github.com/your-org/your-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 on its own branch with the fix. Its description quotes the failing line from the Vercel log, names the component or route file, and explains the cause in SvelteKit's terms, such as a runes mode compile error or a server import in client code. It includes the passing build and the pages it loaded with vite preview.
This repository has no workflow of its own, so the check on the pull request is Vercel's preview deployment for the branch. A reviewer opens the preview, visits the routes the fix touched, and reads the diff to see that it moves the component to runes rather than turning runes off in svelte.config.js.
When the build passes in the sandbox, the cause is in the Vercel project, not the code, and the run reports what differs, such as the Node version or a missing environment variable. Every command and its output stays in the session.
Run it on every failed Vercel deployment
Set up an automation in the Project with this prompt and a webhook trigger, and keep the URL and signing secret Rush shows once. Point the Vercel project's failed deployment webhook at it, and each failure starts a run with the event after the prompt.
One event delivered twice still makes one run. The run opens one pull request on its own branch, and when its checks do not pass it ends needs_review instead of reporting done.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
A SvelteKit failure on Vercel usually means checking out the commit, installing the right pnpm, and running the build with adapter-vercel to see the same compile error. A Rush run does it in its own sandbox and keeps every command and its output, so the fix comes with its own record of how it was found and checked.
With no test suite in the repository, the proof is the passing build, the pages loaded in vite preview, and the green Vercel preview on the pull request. Failures on different branches each get their own run, side by side.
Frequently asked questions
Will it turn off runes mode to make the build pass?
No. The prompt asks for the cause to be fixed, and the reviewer checks svelte.config.js is unchanged. A component written in the old syntax is rewritten with $props() and $state instead.
Does the build need the RealWorld API to be up?
The build does not call it; src/lib/api.js calls https://api.realworld.show/api at request time from the +page.server.js loaders. The vite preview check does need it to load pages with data.
Which package manager does it use?
The one the repository names: pnpm@10.20.0 in packageManager, installed with pnpm-lock.yaml. That matches what Vercel uses for a project with a pnpm lockfile.
How does it read the Vercel build log?
Through the Vercel MCP server, connected once with POST /me/connections and an OAuth sign-in, then named in the run's connections or on the saved agent the automation runs.