What the agent does
A SvelteKit site like sveltejs/svelte.dev is a pnpm workspace, not a single package. The root package.json sets packageManager to pnpm@11.5.3 and the workspace covers apps/svelte.dev plus six packages (repl, site-kit, icons, logos, gzip, docs-types). Versions shared across them sit in the catalog block of pnpm-workspace.yaml: svelte ^5.57.1, @sveltejs/kit ^3.0.0-next.31, vite ^8.3.1, vitest ^4.1.8 and @types/node ^22.19.20. Packages that say catalog: in their package.json take those. So the agent edits the catalog for shared tools and each package.json for the rest, and uses the pnpm version the root names so pnpm-lock.yaml keeps its format.
The workspace file also carries rules the upgrade has to respect. minimumReleaseAge is 2880 minutes, so pnpm refuses any release younger than two days except for the listed @sveltejs/* and Svelte-team packages. blockExoticSubdeps and engineStrict are on, and allowBuilds only lets esbuild, sharp and svelte-preprocess run install scripts. The agent runs pnpm update -r, which stays inside each declared range, under those rules rather than switching them off, and when a newer version is blocked by the release-age rule it says so instead of forcing it.
Tests live in three places. apps/svelte.dev runs node scripts/get_svelte_template.js && vitest run, which first generates the playground's download templates with the sv package, then runs tests such as vercel.test.ts and src/lib/playground-download.test.ts. packages/repl has src/lib/workers/sveltekit.spec.ts, and packages/site-kit has three markdown specs. The root test script, pnpm -r test, runs all three. The agent runs it on the current lockfile for a baseline, then after the update, and also runs pnpm -r package && pnpm check and pnpm lint, because those are what the repository's CI Lint job runs; the CI test job is commented out in ci.yml.
For anything that fails, the agent finds the package responsible by reverting groups of updates and re-running the failing workspace's tests, then puts that package back at its locked version and records the failing test file and message. Some ranges are deliberately unusual here: @vercel/analytics and @vercel/speed-insights are on canary tags, and the kit catalog entry is a 3.0 prerelease with a separate sveltekit-2 catalog beside it. The agent keeps those on the same channel they are on now and lists them separately.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Upgrade this pnpm workspace's npm dependencies to their latest compatible releases. Use the pnpm version in packageManager. Update shared versions in the catalog section of pnpm-workspace.yaml and the rest in each package.json, and keep the existing minimumReleaseAge, blockExoticSubdeps and allowBuilds settings; if a release is too new for minimumReleaseAge, leave it and say so. Keep prerelease and canary dependencies on their current channel. Run pnpm install and pnpm -r test (vitest run in each workspace) before changing anything for a baseline, then after the upgrade, and also run pnpm -r package && pnpm check and pnpm lint. For every package whose upgrade fails a check that passed in the baseline, revert it and record the failure. Open one pull request listing each bump with its old and new version and each skipped upgrade with the error that blocked it.",
"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 pull request touches pnpm-workspace.yaml for catalog entries, the package.json files of apps/svelte.dev and the packages that changed, and pnpm-lock.yaml. Its description lists each package with old and new range, grouped by workspace, then the packages that were reverted with the vitest file and assertion that failed, then the ones held back by minimumReleaseAge with their publish time. Canary and prerelease entries have their own short section so nobody mistakes a canary bump for a stable one.
Reviewers should open the Svelte and Vite release notes for any change in those catalog entries, check the playground download feature by hand if sv moved (get_svelte_template.js depends on its create and add exports), and confirm the Lint job passes on the pull request. Because CI does not run the vitest suites, the session transcript, read through GET /o/{org}/sessions/{id}/messages, is where the test output for this upgrade lives.
Run it on every every Tuesday
Pick the day after your usual release and have a scheduled job send POST /o/{org}/sessions with this request and your repository in resources. A GitHub Actions workflow with a cron schedule and the API key stored as a repository secret is enough. Pass an Idempotency-Key per repository per week so a re-run of the workflow does not open a second branch.
The webhook set on the key reports when the turn is done. Read the session for the pull request URL and add it to your team's review queue. The two-day minimumReleaseAge means a package published on the day of the run waits for the following week, which is the behaviour the workspace already asks for.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
This upgrade is more than one install. The template generator runs before the app tests, three workspaces have their own vitest configuration, and svelte-check has to agree with the new types. The agent needs a machine where it can run all of that repeatedly while it narrows down a failure, and a Rush sandbox gives it one, with each pnpm command and its output saved in the session.
Because the repository's CI skips the test job, a bot pull request that only updates the lockfile looks green even if vitest would fail. A run on Rush does the testing CI does not and puts the evidence in the pull request description. One request per repository also lets several SvelteKit sites get their weekly upgrade at the same time, within the key's concurrency limit.
Frequently asked questions
My project uses pnpm, not npm. Does that matter?
The agent uses whatever the repository declares. svelte.dev sets packageManager to pnpm, so the agent runs pnpm and writes pnpm-lock.yaml; a project with package-lock.json gets npm update and npm test instead. Mixing package managers would produce a lockfile your CI rejects.
Will it touch the pnpm catalog?
Yes, because that is where svelte, vite, vitest and @sveltejs/kit are versioned for the whole workspace. Raising a catalog entry once updates every package that uses catalog: for it, which keeps the workspace on one version of each.
Does it respect minimumReleaseAge?
It does. The setting is a decision the maintainers made about supply-chain risk, so the agent does not override it. Packages too new to install are listed in the pull request with the date they become eligible.
What about @sveltejs/kit prereleases?
The agent keeps a dependency on the channel it is on. The catalog's kit entry is a 3.0 next release, so it moves to a later next release if one exists, and the sveltekit-2 catalog stays on 2.x.