# Turn Linear Issues Into Pull Requests for a SvelteKit App Yes. Give the run a Linear issue and your SvelteKit repository: the agent changes the article or profile route, runs the build and opens a linked pull request. [Run this on Rush](https://cloud.getrush.ai/run/linear-issue-to-pr/sveltekit/), in a Project that has your repository. ## 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` ```json { "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" } ] } ``` 1. **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. 2. **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. 3. **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. ## 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.