What the agent does
A failed Vercel deployment starts the run with the deployment event after the prompt. The agent reads that deployment's build log through the Vercel connection and finds the first real error, which in a Nuxt build can be a Vite transform error, a Nitro prerender failure or a type error from nuxt prepare. It clones the repository at the commit Vercel built into its own cloud sandbox.
In a Nuxt app like elk-zone/elk, the agent reads package.json: nuxt build as build, pnpm@11.6.0 in packageManager, and a postinstall that runs simple-git-hooks && nuxt prepare, so a broken module can fail the install before the build even starts. .nvmrc says lts/*. The CI workflow in .github/workflows/ci.yml enables corepack and runs pnpm install --frozen-lockfile, pnpm nuxi prepare, pnpm test:ci, pnpm lint and pnpm test:typecheck, and the agent uses the same steps.
It reads nuxt.config.ts for build behaviour that depends on where the build runs. The storage driver is process.env.NUXT_STORAGE_DRIVER ?? (isCI ? 'cloudflare' : 'fs'), so on a CI host such as Vercel it expects Cloudflare KV credentials, and netlify.toml notes that without them the build crashes while starting the prerenderer. Nitro prerenders with crawlLinks: true, so one broken link in a page can fail the deployment. The agent sets the same CI condition in the sandbox, with the Project's secrets as environment variables, so its build fails the way Vercel's did.
With the failure reproduced, it fixes the cause in the file the log names, runs pnpm build until it passes, then runs the Vitest suite with pnpm test:ci and the type check with pnpm test:typecheck so the fix does not break something the build does not cover.
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 Nuxt 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 frozen lockfile, reproduce the failure with pnpm build in the sandbox under the same CI conditions and the Project's environment variables, fix the cause, confirm the build, pnpm test:ci and pnpm test:typecheck pass, 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 with the fix on its own branch. Its description quotes the failing line from the Vercel build log, says whether the cause was in a component, a Nuxt module, the Nitro prerender or the configuration, and shows the passing build. Changes to nuxt.config.ts are listed on their own, since they change every build.
Two kinds of checks run on it: the Vercel preview deployment for the branch, and the repository's CI workflow with tests, lint and type check. A reviewer looks at the preview first, then confirms the fix addresses the cause. A prerender failure fixed by excluding the route from prerendering, for example, is a choice the description must state, not hide.
When the failure comes from the Vercel environment rather than the code, such as missing KV credentials for the storage driver, the run says so and names the variable instead of changing code to work around it. Every command it ran and its output stays in the session.
Run it on every failed Vercel deployment
Create an automation in the Project with this prompt and a webhook trigger, and copy the URL and signing secret Rush shows once. Add a webhook in the Vercel project for failed deployments that posts to that URL. Each failure starts one run, with the deployment event passed to the agent after the prompt as untrusted data.
A webhook Vercel sends twice is deduplicated, so one failure gives one run and one pull request. When the automation is busy or rate limited it reports why it skipped an event, and the next failure starts its own run.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
Nuxt builds behave differently on a CI host than on a laptop: this app switches its storage driver on isCI, prerenders by crawling links, and runs nuxt prepare on install. A Rush run reproduces those conditions in its own sandbox instead of on someone's machine, with pnpm from packageManager and every command's output kept.
The pull request carries its proof: a passing build in the session, a green preview on Vercel and the repository's own CI. Failures on several branches each get their own run, and a failure the code cannot fix ends with an explanation rather than a forced change.
Frequently asked questions
The install itself fails. Can the agent handle that?
Yes. In this app postinstall runs nuxt prepare, so a broken module or config fails pnpm install. The agent reads that output the same way it reads a build failure and fixes the cause before running the build.
Which pnpm version does it use?
The one packageManager names, pnpm@11.6.0 in elk-zone/elk, through corepack as the CI workflow does. The lockfile is installed frozen, so the dependency tree matches what Vercel built.
How does it connect to Vercel?
Connect the Vercel MCP server once with POST /me/connections and an OAuth sign-in, then name it in the run's connections or on the saved agent the automation runs. The agent uses it to read the deployment and its build log.
Will it run the Vitest tests too?
Yes. The prompt asks for pnpm test:ci, which runs vitest run, and pnpm test:typecheck after the build passes, so a fix that builds but breaks a test is caught before the pull request opens.