What the agent does
The agent turns a reproducible GitHub issue into a reviewable Express change. In an application like gothinkster/node-express-realworld-example-app, it begins with the actual runner: package.json:8 defines "test": "nx test", and project.json:63 selects "executor": "@nx/jest:jest". The checkout includes package-lock.json, so the agent uses npm ci rather than choosing another package manager. The maintainer supplies the issue number, URL, body, comments and expected behavior; the public repository is a structural example, never the target of the request.
It follows the failing HTTP operation into src/app/routes/article/article.controller.ts. Lines 30–33 handle GET /articles with auth.optional and pass req.query to getArticles; lines 45–54 handle the authenticated feed and convert offset and limit with Number. Those are different paths with different caller expectations. A report about pagination must identify which path it exercises and whether the request is anonymous. The agent reads the matching service and mapper before deciding where a correction belongs.
The reproduction captures the reported response shape and the behavior the maintainer wants instead. jest.config.ts:7 selects ts-jest, and lines 11–14 include source test files. Existing coverage deserves scrutiny: src/tests/services/article.service.test.ts:1 imports prismaMock, and lines 62–64 stub database calls. A new regression should exercise the real affected behavior and, when persistence is involved, a disposable Prisma database. A mocked service success cannot establish that route filtering, ownership or database writes work.
After establishing the failing case, the agent makes the smallest relevant controller, service or mapping change and reruns the reproduction, then npm test. It preserves unrelated article behavior such as comments and favorites. The pull request explains the cause, the failing condition and each command's actual outcome, and includes Closes #
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Fix the triaged GitHub issue supplied after this prompt in this Express repository. Require the issue URL, number, body, relevant comments and acceptance criteria; if absent, report missing context instead of guessing a bug. Read package.json, its lockfile, project.json and Jest configuration. Reproduce the reported article-route behavior with a Jest regression that exercises the real implementation, using a disposable database when needed. Trace controller, authentication, service and response mapping; make only the change needed by the issue. Run the focused test and npm test, report exact results and any setup failures, and open a pull request whose description includes Closes #<issue> using the supplied issue number and explains the cause. Do not merge 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
The result is a pull request containing the article fix and its regression coverage, with a description that links the originating GitHub report. The changed files follow the cause: query normalization belongs near the request boundary; a database selection error belongs in the service that constructs it. The PR records the before-and-after reproduction and full npm test outcome. No test count or successful run is implied by this example page.
A reviewer checks the route's authentication requirements, response fields and failure behavior alongside the acceptance criteria. For an article-list issue, the reviewer compares count, ordering and pagination under the reported caller identity. For a mutation issue, they inspect the persisted result as well as the HTTP status. The reviewer also confirms that the Closes reference points to an issue in the target repository and that unrelated Nx configuration, dependencies and formatting remain unchanged.
Run it on every GitHub issue labeled agent
Your GitHub webhook receiver handles issues.labeled, verifies the delivery and accepts only the approved repository and the maintainer's agent label. It fetches the current issue text and comments, appends them to input and calls POST /o/{org}/sessions with your application resource. This is caller-side routing; the session body shown does not register a webhook or fetch a GitHub issue URL as a resource. Deduplicate repeated deliveries before starting another fix.
Choose issues whose expected behavior is clear enough to test. Keep one active change for a given article bug rather than letting repeated labels produce competing branches. When the session finishes, read its result or use the key's completion webhook to collect the PR link and verification summary. Human review still decides whether the change is ready to merge.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
An article bug can require dependency installation, Prisma setup and a targeted HTTP reproduction even when the final patch is small. Rush runs that work in its own sandbox instead of altering the maintainer's local database or interrupting another branch. The issue carries the requested behavior; the returned PR carries the proposed implementation and the evidence needed to judge it.
Independent labeled issues can run separately within the configured concurrency limit. Each session has its own command record, so an Nx failure, a failing regression and a database preparation error remain distinguishable. A reviewer can inspect the transcript rather than relying on an agent's claim that tests were run. That evidence is especially useful in a repository whose existing service tests rely on Prisma stubs.
Frequently asked questions
Can I use npm test even though this project uses Nx?
Yes. The example package script delegates npm test to nx test, and the Nx project selects Jest. The agent reads that configuration instead of replacing the runner with a standalone Jest command that might skip project settings.
Does adding the label automatically create a Rush trigger?
The example assumes your webhook receiver already routes the selected label to the sessions API. Sending the displayed body starts work only. Configure delivery verification, filtering and duplicate handling in the caller.
Will the agent change database schema for an article bug?
Only an issue that actually requires a schema change should authorize one. Most route regressions should remain within their existing implementation and tests. Any necessary Prisma migration needs an explicit explanation and disposable-database verification.
Can it fix an issue without reproduction details?
It can identify which details are missing, but should not invent acceptance criteria. Include the request, caller identity, observed response and expected response. A focused issue makes the failing regression and review decision much clearer.