What the agent does
The agent opens the failure first: your server hands it the workflow_run event, and it runs gh run view <run id> --log-failed to get the failing step's output. For an Express API like hagopj13/node-express-boilerplate the test step is npm test or yarn test, which package.json defines as jest -i --colors --verbose --detectOpenHandles, so the log reads as Jest output: the failing describe and test names, the expected and received values, and a stack into src/. The agent quotes that block before changing anything, and checks the lint step too, since the same repository also runs eslint . and prettier --check.
Next it sets up what the tests need, reading it from the repository rather than guessing. The boilerplate ships yarn.lock, so the agent installs with yarn install --frozen-lockfile, not npm. Its upstream CI is a .travis.yml that pins Node 12, starts a mongodb service and sets MONGODB_URL, JWT_SECRET, JWT_ACCESS_EXPIRATION_MINUTES and JWT_REFRESH_EXPIRATION_DAYS; a GitHub Actions workflow on a fork carries the same values. src/config/config.js validates the environment with Joi and requires NODE_ENV, and in test it appends -test to the database name, so the agent starts MongoDB in its sandbox and exports the same variables the workflow sets.
The integration tests in tests/integration/auth.test.js and user.test.js call the app through supertest and load users from tests/fixtures/user.fixture.js (userOne, admin, insertUsers) and tokens from token.fixture.js; tests/utils/setupTestDB.js connects Mongoose before the file and empties every collection before each test. The agent runs the failing file alone, such as npx jest -i tests/integration/auth.test.js, follows the stack into src/routes/v1/auth.route.js, the Joi schemas in src/validations/, the controllers and the services, and fixes the code the failing commit changed.
It edits a test only when the test asserts something the API should no longer do, and it says so. Once the failing test passes, it runs the full yarn test and yarn lint so the pull request is green on every step the workflow runs, and Jest's --detectOpenHandles output is clean.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "The GitHub Actions workflow on this branch failed; the workflow_run event is at the end of this prompt. Read the failed job's log with gh run view <run id> --log-failed and quote the failing test or step. Set up the job's environment from the workflow file: the same Node version, the package manager the lockfile shows, a MongoDB service and the environment variables the job sets. Reproduce the failure with the test command the job runs (npm test or yarn test), running the failing Jest file alone first. Fix the cause in the code under src (change a test only if the test is wrong, and say so), run the full test and lint scripts until they pass, and open a pull request against the failing branch that quotes the error it fixed.\n\nEvent: <workflow_run payload>",
"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
A pull request against the failing branch with the fix in the route, validation, controller or service the Jest stack trace named. Its description quotes the failing assertion from the GitHub log, says which step failed, lists the commands the agent reran in its sandbox (the single Jest file, then the full suite and lint), and notes any test it changed and why. The workflow reruns on the pull request, and those checks are the public proof; the trajectory keeps the same commands with their full output.
When the failure is the environment rather than the code, such as a MongoDB service that did not start in time or a Node version the workflow changed, the agent reports that instead of patching around it, and its answer reaches your webhook. A fix to the workflow file itself is proposed only when the log shows the workflow is what broke.
Before merging, a reviewer checks that the change fixes the behavior the test describes, that auth changes in src/middlewares/auth.js or the token service keep the same rights for each role in src/config/roles.js, and that no fixture or secret value was edited to make a test pass.
Run it on every red build on a pull request
Add a webhook for GitHub's workflow_run event and send this request whenever a run completes with conclusion: failure on a pull request branch. Use https://github.com/<owner>/<repo>/tree/<head_branch> as the resource so the clone is the failing branch, and leave out branches the agent opened so a failed fix does not trigger itself.
A key runs at most max_concurrent sessions at once (4 by default) and answers 429 past that, which matters when one bad dependency bump turns many branches red; queue those requests. Remember each workflow_run.id with the execution_id Rush returns, so a GitHub redelivery does not start a second run on the same failure.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
A failing Express test usually needs a running MongoDB, the right Node version and a handful of JWT variables before it reproduces, which is why fixing CI on a laptop takes longer than the fix. The agent sets all of that up in its own sandbox with its own clone, so your local database, your node_modules and your current branch stay untouched.
Everything it claims can be checked. The pull request quotes the error, the trajectory has every install and Jest run with its output, and the workflow runs again on the pull request. Several failing branches each get their own run in their own sandbox, and a person reviews each fix before it merges.
Frequently asked questions
Does it use npm or Yarn?
Whichever lockfile the repository has. node-express-boilerplate has yarn.lock, so it installs with Yarn even if the workflow step says npm test, and it does not add a second lockfile.
Our tests use mongodb-memory-server instead of a MongoDB service. Is that fine?
Yes. It runs whatever the test setup starts. With the boilerplate's setupTestDB.js, which connects to MONGODB_URL, it starts a real MongoDB in the sandbox; with an in-memory server it lets the tests start their own.
Will it weaken validation to make a test pass?
The prompt tells it to fix the code and to change a test only when the test is wrong. If the fix touches a Joi schema in src/validations/, the pull request explains which input the schema now accepts or rejects, so the reviewer can judge it.
What about flaky tests?
If the failing test passes on repeated runs in the sandbox, the agent says it could not reproduce the failure and does not open a pull request. Its answer names the test so you can decide whether to fix the flakiness separately.