What the agent does
The agent starts from the issue. resources names the repository and the Linear issue URL, which Rush reads through your Linear connection and places in the prompt, so the description, the comments and the acceptance criteria are there before the first file is opened.
In a SvelteKit app like sveltejs/realworld, package.json pins @sveltejs/kit 2.52, svelte 5.55 with runes: true in svelte.config.js, vite 7.3 and @sveltejs/adapter-vercel, with pnpm@10.20.0 as packageManager and pnpm-lock.yaml. The scripts are dev, build, preview, lint (prettier --check .) and format; there is no test runner and no .github directory. All data comes from src/lib/api.js, which sends to https://api.realworld.show/api with a Token header, and src/hooks.server.js reads the jwt cookie into locals.user on every request.
The article route is src/routes/article/[slug]/+page.server.js: load fetches the article and its comments in parallel and renders the body with marked and sanitize-html, and the actions are createComment, deleteComment, deleteArticle and toggleFavorite, each refusing with error(401) when locals.user is missing. The profile route is src/routes/profile/@[user]/: +layout.server.js loads the profile, +page.server.js and favorites/+page.server.js call get_articles with author or favorited, paging by page_size from src/lib/constants.js, and the toggleFollow action returns fail(422, result) on an API error. A ticket about favouriting lands in toggleFavorite and ArticleMeta.svelte; a ticket about the follow button lands in toggleFollow and the layout.
With no test runner in the repository, the agent verifies with what exists: pnpm install, pnpm lint and pnpm build, which runs the Vercel adapter; there is no type-check script to add to that. If the acceptance criteria ask for an automated test, the pull request says so and proposes Vitest as a separate change rather than adding a runner inside a feature ticket.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Implement the Linear issue given as a resource in this SvelteKit codebase. Read the issue and its comments first. Make the change in the article or profile route it concerns, in the +page.server.js load or action and the Svelte component that uses it, and keep the diff small. Keep the api.js client and the jwt cookie handling as they are unless the issue changes them. Run `pnpm install`, `pnpm lint` and `pnpm build` and fix what fails; the repository has no test runner, so say so in the pull request and do not add one unless the issue asks. Open a pull request whose description links the issue, explains the change and quotes the lint and build output. Do not merge.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
},
{
"url": "https://linear.app/your-org/issue/ENG-42"
}
]
}- 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
A pull request on its own branch comes back. Its description links the issue, names the route files and component it changed, and quotes the pnpm lint and pnpm build output. The diff stays inside the route the ticket names.
The pull request URL is on the session and in the run.completed webhook, and your handler posts it on the Linear issue, since the sandbox has no Linear tools. The transcript keeps the install, the build and every file the agent read, so a reviewer can see that a change to toggleFavorite was made after reading ArticleMeta.svelte and the form that posts to it.
Before merging, a reviewer runs pnpm dev against the shared RealWorld API and clicks through the changed route, since no automated test covers it, and checks that every action still refuses a signed-out user with 401.
Run it on every Linear issue labeled agent
Create an automation with a linear trigger on linear.issue.labeled, the hand-off label in config.labels and the team keys in config.teams. Each labeled issue starts one run with the issue as its context and this prompt. Labels added by an app integration never fire it.
A linear.issue.state_changed trigger with config.states mapping a review state to plan gives the team a read-only run first: it posts a plan as a comment on the issue and changes nothing. The state mapped to exec starts the run that opens the pull request.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
A SvelteKit change that touches a form action is quick to make and slow to prove without a test runner: someone has to build it, run it and click through. On Rush the agent builds it in its own sandbox and keeps the build output, and the pull request carries that evidence instead of a note that it worked locally.
Separate sandboxes mean three tickets about the profile page run at once without colliding in one checkout. The transcript shows which route files the agent read before changing a load function, which matters in a codebase where every page depends on locals.user set in a server hook.
Frequently asked questions
How does the run see the Linear issue?
Through a resources entry with the issue URL, read with your Linear connection and placed in the prompt before the run starts. Connect Linear once with POST /me/connections {"type": "app", "name": "linear"}; an issue URL with no connection answers 422 RESOURCE_NOT_ACCESSIBLE.
Can it comment the pull request link on the issue?
Not from the sandbox: a Linear sign-in cannot yet be named in connections. The URL comes back on the session and in the webhook, and your handler posts it.
Why does it not run tests?
The repository defines none: no Vitest, no Playwright, no test files. The agent runs pnpm lint and pnpm build and says so in the pull request. Ask for Vitest in its own ticket and the agent sets it up as a separate pull request.
Does the run call the real RealWorld API?
src/lib/api.js points at https://api.realworld.show/api, the shared backend. The prompt asks for lint and build only, which do not call it; running the app against it is the reviewer's manual step.