What the agent does
A red build in a SvelteKit monorepo can come from three different commands, so the agent starts by finding out which one failed. It reads the event that started the run, calls gh run view <id> --log-failed, and maps the failed step back to .github/workflows/ci.yml. In sveltejs/svelte.dev the active job is Lint: it installs with pnpm install --frozen-lockfile on Node 24, runs pnpm -r package && pnpm check as the type check, then pnpm lint. The Tests job is commented out, so a failure there means someone re-enabled it.
Then it sets up the same toolchain in its sandbox. The root package.json pins packageManager to pnpm@11.5.3, and pnpm-workspace.yaml covers apps/* and packages/* with a catalog for svelte ^5.57.1, @sveltejs/kit ^3.0.0-next.31, vite ^8.3.1 and vitest ^4.1.8. It also sets engineStrict, minimumReleaseAge: 2880 and blockExoticSubdeps, so a dependency bump that pnpm refuses fails at install, before any test runs. The agent installs with the frozen lockfile, exactly as CI does, and reads that error before touching code.
It reproduces the failing step with the command that step ran. A type error reproduces with pnpm check, which runs svelte-kit sync && svelte-check in each package after pnpm -r package builds packages/site-kit and packages/repl. A formatting failure reproduces with pnpm lint, which is prettier --check .. A test failure reproduces with npx vitest run in the package that owns it: packages/repl, packages/site-kit, or apps/svelte.dev, where the test script first runs node scripts/get_svelte_template.js to generate the playground's download templates and then vitest run picks up files like src/lib/playground-download.test.ts and vercel.test.ts.
With the error reproduced, it fixes the cause in the route or component the log points at, such as a prop type under src/routes/(authed)/playground/ or a missing export in packages/repl. The repository's AGENTS.md asks for pnpx prettier --write on every changed file, so the agent runs it before committing; otherwise its own fix could turn the lint step red. It reruns the failing command until it passes, then opens a pull request against the failing branch that quotes the original error.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "The CI workflow failed on the branch docs/new-tutorial. Find the failed run with `gh run list --branch docs/new-tutorial --status failure --limit 1` and read it with `gh run view <run id> --log-failed`. Check out that branch, install with `pnpm install --frozen-lockfile`, and rerun the exact step that failed: `pnpm -r package && pnpm check` for type errors, `pnpm lint` for formatting, or `npx vitest run` in the package whose test failed. Fix the cause in the code; change a test only if the test is wrong, and say so. Run `pnpx prettier --write` on every file you change. Confirm the failing command passes, then open a pull request against docs/new-tutorial that quotes the error and names the step it fixed.",
"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
The result is a pull request against the branch that failed. Its diff is usually small: a .svelte or .ts file under apps/svelte.dev/src/ or one of the packages/, plus any formatting Prettier applied to the same files. The description names the failed step (type check, lint or a Vitest file), quotes the error from the log, and says whether a test was changed and why.
Pushing the branch runs ci.yml again, so the pull request carries its own Lint check, and a reviewer sees it pass where the original run failed. The session record has the full output of the first command that reproduced the failure and of the last one that passed, which matters in a workspace where svelte-check can print hundreds of lines across several packages.
A reviewer checks that the fix touches the file the error named, that no // @ts-ignore or svelte-ignore comment was added to silence a real type error, and that Prettier changes are limited to files the fix needed. If the failure was an install refusal from minimumReleaseAge, the pull request should explain the dependency and its publish date rather than relax the setting.
Run it on every red CI on a pull request branch
Create an automation in the Project for this repository with the prompt above and a GitHub trigger on workflow_run.failure. Every failed workflow run starts one Rush run, and the event that fired it follows the prompt as data, so the agent reads the branch and run id from it instead of searching. Workflows run from forks never fire, so a contributor's pull request from their own fork does not start an agent.
To keep the agent on work your own team pushed, filter the trigger with authors (GitHub logins), and cap max runs per hour so a docs sync that fails repeatedly does not start one run per push. When a run ends, the pull request it opened appears on the failing branch, where its author already looks.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
Reproducing a SvelteKit CI failure locally means matching pnpm 11, Node 24 and a frozen install across a workspace with several packages, then running the build that pnpm check depends on. On Rush the agent does this in a sandbox with its own clone, so a svelte-kit sync that rewrites .svelte-kit/ or a template script that writes into static/ changes nothing on your machine.
The fix comes back as evidence, not a claim. The workflow that failed runs again on the pull request, and the session keeps every command and its output, from --log-failed to the passing pnpm check. When several branches go red after one bad catalog bump, each failure starts its own run in its own sandbox, and each branch gets its own pull request.
Frequently asked questions
Which command does the agent use to reproduce the failure?
The one the failed step ran. In this repository that is pnpm -r package && pnpm check for the type check and pnpm lint for formatting; for a test job it runs npx vitest run in the package that failed. It reads the step from the log rather than running every command.
Will it reformat my whole repository with Prettier?
No. It runs Prettier on the files it changed, as the repository's AGENTS.md asks, so the diff stays limited to the fix. If pnpm lint failed on a file the branch already touched, it formats that file and says so in the description.
Does it need Playwright or a browser to fix my tests?
Only if the failing test does. The sandbox has a browser, so it can install Chromium for a Playwright job; for Vitest unit tests like the ones in packages/repl and apps/svelte.dev, it runs them headless with vitest run.
What if the failure is a dependency pnpm refused to install?
It reads the install error, finds which package and version broke a rule such as minimumReleaseAge or blockExoticSubdeps, and fixes the dependency choice in the branch, for example by pinning the previous release. It does not loosen the workspace settings without saying why in the pull request.