What the agent does
A failed workflow on the default branch starts the run. The event gives the agent the workflow name, the head commit and the failing check runs, which in a TypeScript library already say a lot: a matrix job named for a TypeScript version, a lint job or a circular-import check. It clones the commit into its sandbox and reads the failed job's log with gh run view --log-failed.
In a library like colinhacks/zod, .github/workflows/test.yml has three jobs. test-node installs with nub install --frozen-lockfile, runs nub run build, swaps in TypeScript 5.5, 6 or latest with nub add typescript@<version> -Dw, then runs nub run test and the @zod/resolution and @zod/integration suites. lint runs format:check and lint:check (both Biome) and check:comments. check-circular runs madge --circular over packages/zod/src. The root package.json declares "packageManager": "nub@0.8.3", .nvmrc says Node 24, and the workspace lockfile is pnpm-lock.yaml.
The agent reproduces the exact matrix leg. A failure only on typescript@latest is installed that way before running anything, because Zod's vitest.config.ts turns on Vitest typecheck with checker: "tsc" and ignoreSourceErrors: false, so a type error in a .test.ts file fails the suite even when every runtime assertion passes. It also loads scripts/fail-on-console.ts as a setup file, so a stray console.log fails a test. The agent runs the one failing project or file first, then the full nub run test.
It fixes the cause in packages/zod/src/ or in the test the commit broke: a type that a newer compiler narrows differently, an import cycle madge found, a Biome rule the change violates. Before opening the pull request it reruns build, test, format:check, lint:check and check:circular, the same set CI runs.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "The GitHub Actions run on the default branch failed; the event follows this prompt. Read the failed job's log and name the job, the Node and TypeScript versions, and the failing test, type error or check. Install with the package manager and frozen lockfile the repository declares, match that TypeScript version, reproduce the failure with the job's exact command, and fix the cause. Then run the build, the tests, the formatter check and the linter. Open a pull request that quotes the failing log lines and explains the fix. Do not skip, mark flaky or delete a failing test, and do not add @ts-ignore or @ts-expect-error to get a type check through.",
"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 description names the job and its TypeScript version, quotes the tsc or Vitest error with file and line, and shows that command failing and then passing in the sandbox. A change to package.json, the lockfile or tsconfig.json is called out separately from the source fix.
The full matrix runs again on the pull request, so a reviewer sees TypeScript 5.5, 6 and latest all green rather than taking the sandbox's word for the version it ran. They check that no @ts-ignore, @ts-expect-error, .skip or any cast arrived with the fix, and that a type change in a published package is one consumers can absorb.
When a failure depends on something outside the repository, such as a newly published TypeScript nightly behaving differently, the run reports what changed and where, so the decision to pin or adapt is made by a person with the evidence in front of them.
Run it on every failed test workflow on main
Add an automation to the Project for this repository with the prompt above and a github trigger on workflow_run.failure, branch pattern main. One failed test run with several red matrix legs is one event, so it starts one agent run that sees every failing check name at once.
Redelivered events are dropped, forks are ignored, and the runs-per-hour limit stops a broken typescript@latest release from starting a run per repository faster than you choose.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
Fixing a TypeScript matrix failure by hand means installing the right package manager, matching a compiler version you may not have, and rerunning a build and a type-checked test suite that can take a while on a large workspace. A Rush run does that in its own sandbox and keeps each command's output, so the reviewer can read the exact tsc error before the fix and the clean run after it.
A new TypeScript release can break type tests in many libraries in one day. Each failure gets its own run on its own branch at the same time, nothing touches a developer's local node_modules, and each ends in a pull request whose matrix proves the fix, or a report that says why there is none yet.
Frequently asked questions
Does it work with pnpm, npm, Yarn or Bun?
Yes. It reads packageManager and the lockfile and installs with that tool and its frozen-lockfile flag, the same way the workflow does. Zod's nub is installed from the version the repository pins.
Will it add @ts-ignore to get the type check through?
No. The prompt forbids @ts-ignore and @ts-expect-error as a fix, and Vitest typecheck with ignoreSourceErrors: false would still report source errors. A suppression in the diff would be the first thing a reviewer sees.
Can it fix a failure that only happens on one TypeScript version?
Yes. It installs that exact version, as the matrix job does with typescript@5.5 or typescript@latest, reproduces the error, and then checks the fix against the other versions the workflow tests.
What if lint fails, not the tests?
It runs the lint job's own command, Biome's check and lint in Zod, and fixes the code the rule flags instead of changing biome.jsonc. A rule change, if the agent thinks one is right, is proposed separately in the description.