What the agent does
The run starts from the failure itself. With a GitHub trigger on workflow_run.failure, Rush puts the event that fired it after your prompt, so the agent knows the workflow, the branch and the run id before it opens a file. It calls gh run view <id> --log-failed in its sandbox and reads only the steps that went red, then checks out the failing branch. In a NestJS API like lujakob/nestjs-realworld-example-app, that log usually ends inside npm test, which is jest --config=jest.json, with a testRegex of /src/.*\.(test|spec).(ts|tsx|js)$.
Next it reproduces the failure before changing anything. It reads package.json and sees NestJS 7 (@nestjs/core ^7.0.5), TypeORM ^0.2.24, TypeScript ^3.8.3 and ts-jest 25 wired through ts-jest/preprocessor.js. The repository carries both package-lock.json (lockfile version 1, still stamped with app version 1.1.4 while package.json says 2.0.0) and yarn.lock, so the agent installs with whichever lockfile the workflow used, and says so if the two disagree. Then it runs npm test and confirms it gets the same error the log shows. A failure it cannot reproduce is reported as that, not patched blind.
Some failures come from the environment, not the code. src/tag/tag.controller.spec.ts calls TypeOrmModule.forRoot() with no options, which reads an ormconfig.json that .gitignore excludes; only ormconfig.json.example with a mysql connection is committed. src/config.ts is ignored too, and auth.middleware.ts, user.service.ts and user.decorator.ts all import SECRET from it. When the log shows Cannot find module '../config' or a TypeORM connection error, the agent fixes the workflow step that should create those files, or the test that should not need a database, rather than committing a secret.
When the cause is in the code, such as a change in src/article/article.service.ts that broke how findAll builds its query for tag, author or favorited, it fixes the service and leaves the test alone, unless the test asserted something wrong. Either way it runs npm test again until it passes, pushes the fix to a new branch based on the failing one and opens a pull request against that branch, quoting the error line from the original log.
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 feature/article-filters. Find the most recent failed run with `gh run list --branch feature/article-filters --status failure --limit 1` and read its log with `gh run view <run id> --log-failed`. Check out that branch, install with the lockfile the workflow uses, and reproduce the failure with `npm test` (jest --config=jest.json). Fix the cause in the code under src/; change a spec only if the spec itself is wrong, and say so in the pull request. If the failure comes from a missing ormconfig.json or src/config.ts in CI, fix the workflow step that should provide it and never commit a real secret. Confirm `npm test` passes, then open a pull request against feature/article-filters that quotes the error it fixed and names the file that caused 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
What comes back is a pull request whose base is the branch that failed, not your default branch. Its diff is the fix: usually a change under src/article/, src/user/ or src/profile/, sometimes a change to the workflow file when CI was missing ormconfig.json or src/config.ts. The description quotes the line from the failed job's log, says which file caused it and whether any spec changed, and lists the command it ran to confirm the fix.
The proof is the pull request's own checks. Pushing the branch runs the same GitHub Actions workflow that failed, so a reviewer sees the red run on the original branch and the new run on the fix side by side. The session's record keeps every command the agent ran in its sandbox, including the first npm test that reproduced the failure and the last one that passed, with their output.
Before merging, a reviewer checks that the fix addresses the cause the log named rather than silencing it, that no spec was loosened without a reason in the description, and that any workflow change creates config files from GitHub Actions secrets instead of hard-coded values. Merging the fix into the failing branch turns that branch's own pull request green again.
Run it on every failed workflow run
In the console, add an automation to the Project that holds this repository, with this prompt and a GitHub trigger on workflow_run.failure. Each failed run starts its own Rush run, with the event after the prompt so the agent knows which workflow and branch went red. Only work by an owner, member or collaborator fires it, and CI runs from forks never do, so an outside pull request cannot start an agent on your account.
Set the automation's max runs per hour so a flaky suite that fails on every push does not start a run for each one. Each run opens at most one pull request on its own branch; when the agent cannot reproduce the failure, its answer says what it tried instead of opening an empty pull request.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
Fixing CI on a laptop means stashing what you were doing, checking out the broken branch, matching the Node and npm versions the runner used and installing from the right one of two lockfiles. In Rush the agent does that in a sandbox of its own, with its own clone and its own node_modules, so your working copy and your local MySQL stay as they were. It reads the runner's log with gh, runs npm test there and keeps the output of every command.
Failures also arrive in bursts: one bad merge can turn several feature branches red at once. Each workflow_run.failure starts a separate run in a separate sandbox, so three branches get three pull requests in parallel, each one checked by the same workflow that failed. The reviewer judges the fix from the diff, the checks and the record of what the agent ran, not from a summary.
Frequently asked questions
Will the agent push to my failing branch directly?
No. It pushes a new branch and opens a pull request against the branch that failed, so the person who owns that branch decides whether to take the fix. Nothing reaches your default branch unless you merge it there yourself.
My NestJS tests need MySQL. Can the agent run them?
The agent works in a full sandbox, so it can install and start a database there when the spec needs one, the way TypeOrmModule.forRoot() in this repository does. It reads the connection settings from your example config rather than inventing them. If the failure only happens against your production database, it says so instead of guessing.
What if the test is wrong, not the code?
The prompt allows changing a spec only when the spec asserts the wrong thing, and requires the pull request to say so. A reviewer then sees the spec change called out in the description and can reject it if the old assertion was right.
Does it work with yarn or pnpm instead of npm?
Yes. It installs with the lockfile your workflow uses: package-lock.json, yarn.lock or pnpm-lock.yaml. In a repository that has more than one, like this one, it follows the install command in the workflow file and mentions the extra lockfile in its answer.