What the agent does
In honojs/examples the agent reads the root package.json first: an npm workspace with packageManager npm@10.0.0 and nine members, basic, blog, durable-objects, jsx-ssr, pages-stack, nextjs-stack, hono-vite-jsx, env-vars and stytch-auth, while deno, bun and serve-static sit outside the workspace with their own files. There is no lockfile anywhere in the tree and no CI workflow, only a dependabot.yml under .github, so the baseline is whatever npm install resolves today, and the pull request has to record the resolved versions itself.
Each member declares hono ^4.2.4 and its own tooling. basic has vitest ^1.5.0 and wrangler ^3.53.0 with a test script of vitest --run and a src/index.test.ts that calls app.request against http://localhost/ and checks the x-powered-by header. blog pins vitest to 1.3.0 beside @cloudflare/vitest-pool-workers ^0.2.0 and runs its api.test.ts inside workerd through defineWorkersConfig with the wrangler.toml, using env from cloudflare:test. durable-objects, env-vars and jsx-ssr have only dev and deploy scripts on wrangler. hono-vite-jsx, pages-stack and stytch-auth build with vite, and nextjs-stack builds with next. Those differences decide the check for each member: the test script where one exists, the build script where one exists, and npx wrangler deploy --dry-run for the Workers that have neither.
The agent runs npm install at the root, then runs every member's check once for a baseline and keeps the output. It runs npm outdated --workspaces, applies npm update --workspaces so each caret range moves to its newest version, and reruns every check. Two packages need care here: vitest in blog is pinned because the vitest-pool-workers release it uses is built for that vitest line, so the agent raises both together or neither; and wrangler ^3.53.0 sits a major behind, so a wrangler 4 bump is tried per member and kept only where wrangler deploy --dry-run still accepts that member's wrangler.toml.
A failure is bisected per member by restoring half of the bumps at a time until one package remains, which goes back to its previous version with the error recorded. hono itself moves within its caret range in every member in one step, since the examples are meant to show the same Hono version. Majors outside a range, such as a new wrangler, vitest or next, are listed with their versions and left for a planned upgrade unless a member's check passed with them.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Upgrade the npm dependencies to the latest compatible versions with npm in each example. Read the root package.json to find the workspace members and note that the repository keeps no lockfile. Run npm install at the root, then for a baseline run each member's test script where it has one, its build script where it has one, and npx wrangler deploy --dry-run for the Workers examples that have neither. Run npm update --workspaces so each caret range moves to its newest version, keeping vitest and @cloudflare/vitest-pool-workers in blog on versions built for each other, then run the same checks again. Leave out any upgrade that breaks a member's test, build or dry-run deploy and say why with the error. Open a pull request with one line per bump per member, including the resolved versions.",
"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 changes the package.json of each member whose range moved, and nothing else, because there is no lockfile to commit. The description lists the bumps grouped by member with the old and new ranges and the version npm resolved, then the bumps left out with the member, the command and the error, and a short list of majors outside the current ranges with their versions.
A reviewer runs npm install and the checks locally for the members they deploy, reads the blog lines first because the Workers test pool and vitest must match, and checks that each wrangler.toml still has the compatibility_date the member needs. The session record holds the baseline, every npm command and every check, so an excluded bump can be retried in a follow-up message to the same session.
Run it on every Monday morning
A scheduled workflow sends POST /o/{org}/sessions with this request and your repository in resources, with the org key as the bearer token and an Idempotency-Key made of the repository and the week, so a re-run returns the run already started.
Put a webhook URL on the key. When the turn ends your endpoint receives run.completed with session_url, reads the pull request link from the session and posts it to the channel where the examples are reviewed.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
A repository of small apps is slow to upgrade by hand because each one has a different check: a vitest run, a workerd test, a vite build, a next build or a wrangler dry run, and each has to be run after every bump. In a Rush sandbox the agent runs all of them as many times as the bisection needs, with its own install and no leftover node_modules on your machine.
Every command's output is kept in the session, so the pull request says what was tested rather than asking the reviewer to assume. Several example or template repositories can get the same request at once, each in its own sandbox, up to the key's concurrency limit.
Frequently asked questions
What is the check for a member with no test script?
The build script when there is one, as in hono-vite-jsx, pages-stack and nextjs-stack, and otherwise npx wrangler deploy --dry-run, which bundles the Worker and validates its wrangler.toml without deploying. The pull request names the check that was run for each member.
Why does blog pin vitest?
Its tests run inside workerd through @cloudflare/vitest-pool-workers, and each release of that pool is built for a particular vitest line. The agent moves the two together only when the api.test.ts suite still passes, and otherwise leaves both where they are and says so.
Does it touch the deno and bun examples?
No. They are outside the npm workspace and have no package ranges npm manages. The prompt names npm in each example, and the pull request lists them as skipped.
Will it move wrangler to version 4?
It tries, member by member, and keeps the bump only where the member's test or dry-run deploy passes with it. A member that fails stays on wrangler 3 with the error quoted, so the team can plan the config change.