What the agent does
In alan2207/bulletproof-react, the Vite app is apps/react-vite, one of three separate apps that each install on their own: the root package.json has no workspaces and its prepare script simply cds into each app and runs yarn. So the agent works inside apps/react-vite, where yarn.lock is a Yarn v1 lockfile and package.json lists 30 dependencies and 60 dev dependencies. Among them are react ^18.3.1, react-router ^7.0.2, @tanstack/react-query ^5.32.0, zod ^3.23.4 and react-hook-form ^7.51.3, with vite ^5.2.10, vitest ^2.1.4, msw ^2.2.14, typescript ^5.4.5, eslint 8 and Storybook 8 on the dev side.
The agent copies .env.example to .env, as the React Vite CI workflow does, because the app reads VITE_APP_API_URL and VITE_APP_ENABLE_API_MOCKING at build time. It runs yarn outdated, then yarn upgrade to move each package to the newest version inside its declared range, which keeps the update within what the authors allowed. Majors that are available outside a range, such as a newer Vite or Vitest, are listed in the pull request rather than applied, since they change config formats and test APIs.
The checks are the ones CI runs in its all-cli-checks job: yarn build, which is tsc followed by vite build --base=/, yarn test, yarn lint and yarn check-types. The test script is plain vitest, which watches in an interactive terminal, so the agent runs yarn test --run to get a single pass. There are twelve test files, for the discussions routes, the dialog, drawer, form and notification components, the login and register forms, use-disclosure and authorization. src/testing/setup-tests.ts starts an MSW server with onUnhandledRequest set to error and mocks zustand, so an msw or zustand upgrade that changes those APIs shows up as a failing test straight away.
For each failure, the agent bisects the upgraded set by restoring halves of yarn.lock and re-running the failing command until one package is left. That package goes back to its locked version, and the agent keeps the test name or TypeScript error that it caused. Playwright end-to-end tests in e2e need a mock server started through pm2 and browsers installed with --with-deps; the agent runs them when it can and says plainly in the pull request if it did not.
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 yarn, working in apps/react-vite. Copy .env.example to .env first, as CI does. Before changing anything run yarn install, yarn build, yarn test --run, yarn lint and yarn check-types for a baseline. Run yarn upgrade so each package moves within its declared range, then run the same commands. Leave out any upgrade that breaks the build, tests, lint or type check and say why with the error. List newer major versions that are outside the current ranges without applying them. Open a pull request with one line per bump.",
"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 apps/react-vite/yarn.lock, and package.json only if a range had to be raised for a package the tests accept. The description has one line per package with old and new version, sorted with runtime dependencies first. It then lists the upgrades left out, each with the command and error, and a short table of majors that are available but not applied (Vite, Vitest, ESLint, Storybook, React and others when they apply), so the team can plan those separately.
A reviewer checks that the React Vite CI workflow passes on the pull request, including the e2e job with Playwright, then runs yarn dev and clicks through the discussions pages against the MSW mock API. TanStack Query and react-router minor releases sometimes change behaviour that tests do not cover, so those lines deserve a look at their changelogs.
Run it on every Friday afternoon
Have a scheduled workflow call POST /o/{org}/sessions with this request and your repository in resources. Keep the API key in your CI secrets, send it as the Bearer token, and pass an Idempotency-Key made of the repository and date so that re-running the workflow returns the run already started.
Put a webhook URL on the key. When the turn finishes, your endpoint receives a signed run.completed event; fetch session_url for the pull request link and post it to the frontend channel, ready for Monday's review.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
Finding which of a few dozen updated packages broke a test means installing, building and running vitest again and again. That fights with the dev server and node_modules a developer is using. A Rush sandbox gives the agent its own copy of the repository and its own install, runs every yarn command as many times as the bisection needs, and keeps each command's output in the session record.
A per-package bot opens a dozen pull requests a week for an app like this and leaves the team to find the one that breaks login-form.test.tsx. The agent opens one, already tested, with the broken upgrades taken out and named. Many front-end repositories can run the same request at once, up to the key's concurrency limit.
Frequently asked questions
Does it work with Yarn 1?
Yes. bulletproof-react uses a Yarn v1 lockfile, so the agent uses yarn upgrade and writes the same lockfile format back. A repository on a newer Yarn or on pnpm gets that tool's own upgrade command.
Why yarn test --run instead of yarn test?
The test script runs vitest, which watches for changes when it thinks a person is at the terminal. --run makes it run the suite once and exit with a status the agent can act on, which is what CI needs as well.
Will it upgrade React or Vite to a new major?
No. yarn upgrade stays within each package's declared range, so React stays on 18 and Vite on 5. Newer majors are listed in the pull request with their versions so you can schedule them on purpose.
What about the other apps in the repository?
The prompt names apps/react-vite. The Next.js apps beside it have their own lockfiles, so each can get its own request with its own directory and commands.