What the agent does
The run starts with the issue text in the prompt and the repository cloned into its own cloud sandbox. Take a report against a SvelteKit app like sveltejs/realworld: "A profile with more than ten articles shows only the first ten, and there are no page links." The agent reads package.json first: SvelteKit 2 with Svelte 5 and Vite 7, pnpm@10.20.0 as the package manager with a pnpm-lock.yaml, Node 20 from .nvmrc, and scripts for dev, build, preview and Prettier, but no test script and no test runner installed.
Then it traces the report through the routes. src/routes/profile/@[user]/get_articles.js asks the API for page_size articles (10, from src/lib/constants.js) and returns { articles, pages }. But src/routes/profile/@[user]/+page.server.js destructures { articles, page } from it and returns page, which is always undefined, and the favorites loader repeats the mistake. +page.svelte renders only ArticleList, never the Pagination component that the home page passes pages to. The home loader in src/routes/+page.server.js reads the page number from the URL; the profile pages render no link to page two, so only a hand-typed ?page=2 reaches it.
Before fixing anything the agent writes the failing test. It adds Vitest as a dev dependency with pnpm add -D vitest, a test script, and a test that calls the profile load with a stubbed fetch answering articlesCount: 25, asserting the loader returns three pages. The stub sits at the network edge, where src/lib/api.js calls https://api.realworld.show/api, so the test needs no live backend. It runs npx vitest run and sees the test fail for the reason the issue describes.
The fix follows the home page's pattern: the profile and favorites loaders return pages and the current page number, and both pages render Pagination with links that keep the profile path. The agent runs npx vitest run until it passes, then pnpm build and pnpm lint so the change compiles and matches the Prettier config, and opens the pull request.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Fix the GitHub issue that follows this prompt. Reproduce the reported behavior in the article and profile routes with a Vitest test, fix the code until `npx vitest run` passes, and open a pull request whose description says `Closes #<issue>` and explains the cause.\n\nIssue #12: Profile pages show only the first 10 articles. Open the profile of an author with more than 10 articles: the list stops at 10 and there are no page links, on both the articles and favorites tabs. The home page paginates correctly.",
"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 says Closes #12 and explains the cause in a sentence: the loaders returned page where the helper gives pages, and the profile pages never rendered Pagination. In an app shaped like the RealWorld example the diff touches the two profile loaders, the profile layout or pages that render the links, package.json and pnpm-lock.yaml for Vitest and the test script, and a new test file beside the route.
A reviewer checks that the test failed before the fix and passes after it, which the session's record shows in order, and that the page links on the profile keep the current tab. Merging the pull request closes the issue through GitHub's own Closes keyword.
The session read returns the repository and the pull request, and the transcript holds every command with its output: the dependency install, the failing Vitest run, the passing one, the build and the Prettier check.
Run it on every GitHub issue labelled agent
In the console, add an automation to the Project with a GitHub trigger on issues.labeled, filtered to the agent label, and this prompt. Only work by an owner, member or collaborator of the repository fires it, by GitHub's author_association, so a stranger cannot start runs on your repository. Each labelled issue starts its own run, which works on its own branch and opens its own pull request.
The same request can come from your own server with the issue's text after the prompt. Set a webhook URL on the API key and Rush POSTs run.completed when the turn finishes, with the session_url to read the pull request from.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
This fix is only trustworthy if the test failed first. A run on Rush installs the app with pnpm in its own sandbox, records the failing Vitest run, the fix and the passing run in order, and keeps that record on the session, so the reviewer does not have to rebuild the reproduction to believe it.
Triage becomes the whole job for a maintainer. Label five issues after reading them and five runs start, each in its own sandbox and branch, each ending in a pull request that closes its issue, while the maintainer's own checkout stays on whatever they were doing.
Frequently asked questions
My SvelteKit app has no tests. Will the agent add a test runner?
Yes, when the prompt asks for a Vitest test and none is installed. It adds vitest as a dev dependency with the repository's package manager, adds a test script, and keeps the lockfile in the same commit, which the pull request shows.
How does it test a load function that calls an external API?
It stubs fetch in the test, at the point where src/lib/api.js makes the request, and returns the response shape the real API sends. The loader's own code runs unchanged, so the test catches the bug in the loader rather than in a mock of it.
Can anyone start a run by opening or labelling an issue?
No. The trigger fires only for work by an owner, member or collaborator of the repository, as GitHub's author_association reports it, and events from forks never fire. Labelling stays a maintainer's decision.
What if the issue cannot be reproduced?
The agent says so in its final answer with what it tried, rather than changing code to make a test pass. You can reply with more detail as a follow-up message to the same session, and it continues in the same sandbox.