What the agent does
The agent checks out the pull request and reads what it changes in the article routes. In an Express API like gothinkster/node-express-realworld-example-app those live in src/app/routes/article/: article.controller.ts registers the handlers (GET /articles, POST /articles, the PUT and DELETE on a slug, comments and favorites), and article.service.ts holds the logic they call, from getArticles and getFeed to addComment, deleteComment, favoriteArticle and unfavoriteArticle. The agent maps each changed handler to the service function behind it and lists the branches no test reaches, such as a new filter in getArticles or a new ownership check in updateArticle.
Next it reads how the repository tests services today. package.json runs nx test as its test script, and jest.config.ts uses ts-jest with tsconfig.spec.json and matches any *.test.ts or *.spec.ts under src/. The existing tests live in src/tests/services/ (article.service.test.ts, auth.service.test.ts, profile.service.test.ts, tag.service.test.ts) and in src/tests/utils/. They import prismaMock from src/tests/prisma-mock.ts, a mockDeep<PrismaClient>() from jest-mock-extended that is reset before every test, and set the Prisma calls each case expects, such as prismaMock.comment.findFirst.mockResolvedValue(null).
The agent writes the new cases into article.service.test.ts in the same Given, When, Then shape, one describe per service function, with the Prisma rows typed the way src/prisma/schema.prisma defines them. Each case asserts what the caller sees: the mapped article, the thrown HttpException with its status, or the arguments the service passed to Prisma when that is the behavior the pull request changed. It awaits every promise it asserts on, so a rejected call fails the test instead of passing silently.
Then it runs npm test and reads the Jest output. A test that fails because it set up the mock wrong gets fixed. A test that fails because the service now does the wrong thing stays out of the commit, since the prompt says not to change application code, and the agent explains the failure in its comment instead.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "This pull request changes the article routes. Read the diff against the base branch and list the new or changed behavior in src/app/routes/article/ (the controller and article.service.ts) that no existing test covers. Write Jest tests for each item in src/tests/services/article.service.test.ts, following the existing style: the prismaMock from src/tests/prisma-mock.ts, one describe per service function, Given/When/Then, and await every promise you assert on. Run npm test until the new tests pass. Do not change application code: if a test fails because the code is wrong, leave it out of the commit and describe the failure. Push the tests to this pull request's branch and post a comment listing each test and the behavior it covers.",
"resources": [
{
"url": "https://github.com/your-org/your-app/pull/123"
}
]
}- 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 commit on the pull request's branch that only touches files under src/tests/. In a repository shaped like the Express RealWorld API that is usually src/tests/services/article.service.test.ts, with a new describe block for each service function the pull request added and new test cases inside the blocks it changed. No package is added: Jest, ts-jest and jest-mock-extended are already in devDependencies.
The agent's comment on the pull request lists every test, the behavior it covers ("rejects an update from a user who is not the author") and the npm test run it made. If a test exposed a bug in the change, the comment says which assertion failed and which line of article.service.ts it points to. Your CI then runs the suite on the pushed commit, and that check is the proof the tests pass outside the sandbox.
Before merging, a reviewer checks that the mocked Prisma calls match the queries the service really makes, so a test cannot pass against a query the code never runs. They also check that the tests assert behavior a client of the API depends on, not incidental details such as the order of keys in a Prisma include.
Run it on every pull request opened
Put this prompt in an automation on the Project bound to your API's repository and add a GitHub trigger on pull_request.opened. Each pull request opened by someone who can write to the repository starts a run, and the run's prompt names the pull request, its URL, title, author and base branch. Pull requests from forks never fire it. Add pull_request.synchronize to the same trigger if you want new pushes covered as well.
From your own server, the equivalent is GitHub's pull_request webhook: on opened, send this request with the pull request's URL in resources, which clones its branch, and the delivery id as Idempotency-Key. Set a webhook URL on the API key and Rush POSTs run.completed or run.failed when the run's turn finishes, with the session URL to read the full answer.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Writing tests for someone else's pull request usually means stashing your own work, switching branches, reinstalling node_modules for the Nx workspace and running Jest until the mocks line up. On Rush the agent does that in its own sandbox with its own clone at the pull request's branch, so your checkout and your running dev server stay where they were, and several pull requests get tests at the same time.
Every claim in its comment can be checked. The trajectory keeps each npm test command with its full output, including the runs that failed before the agent fixed a mock, and the CI run on the pushed commit repeats them on your own runner. The tests reach the reviewer in the same pull request as the change, instead of in a coverage cleanup weeks later.
Frequently asked questions
Does it test the Express routes or only the services?
It follows the repository. The Express RealWorld API tests its services with a mocked Prisma client and keeps HTTP-level tests in a separate e2e project, so the new tests go into src/tests/services/. If your repository already uses supertest against the Express app, the agent adds route tests there instead.
Will it start a real database?
Not for these tests. They run against the mockDeep<PrismaClient>() in src/tests/prisma-mock.ts, which is how the existing suite works, so npm test needs no database. If your suite runs against Postgres, say so in the prompt and the agent starts one in its sandbox and applies your Prisma migrations first.
Does it work with Vitest or Mocha instead of Jest?
Yes. It reads the test script and config the repository has and writes tests for that runner. Change npm test and the runner's name in the prompt to match, and the pushed tests use the same imports and assertion style as the files next to them.
What does it do with a pull request that has nothing to test?
It says so in a comment and pushes nothing. A change to types, logging or documentation does not get a test written to raise a number.