What the agent does
The issue is small and well-described: a search box on the home page that filters articles by title through a ?q= query parameter handled in the load function, so results are shareable by URL. The run starts with the issue text in the prompt and the repository cloned; in sveltejs/realworld that repository is SvelteKit 2.52 with Svelte 5, pnpm 10 pinned in the packageManager field, and plain JavaScript with jsconfig, and the agent reads those facts before touching anything.
The home page is exactly where the change belongs. src/routes/+page.server.js already loads the feed from URL parameters: it reads tab, tag and page from url.searchParams, maps page to limit and offset with page_size 10 from src/lib/constants.js, and fetches through the api client in src/lib/api.js. The agent adds one line to that pattern, reading q from the search params, and filters the returned articles by title before they reach the page. It does not invent a server-side search parameter: the RealWorld API has none for titles, and filtering the loaded list keeps the change honest and shareable, because the query string drives a server load.
The UI follows the existing conventions rather than adding a new mechanism. The page already derives its state from $page.url.searchParams for tab, tag and page, so the search input updates the q parameter through the same goto pattern, and a form with method GET keeps it working without JavaScript. Pagination keeps q in the links so a filtered result page stays filtered.
The repository has no test runner at all, no test script and no vitest config, so the agent says so and adds the smallest one: vitest with tests for the load function covering the q filter, the empty state, and pagination math, plus a component test for the input. Then it runs the checks the repository does have, pnpm build and pnpm lint, which is prettier --check, and fixes what they flag. The pull request it opens links back to the Linear issue.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Linear issue labeled agent says: \"Add Article Search to a SvelteKit App. Add a search box on the home page that filters articles by title through a ?q= query parameter handled in the load function, so results are shareable by URL.\" Do the work in this repository, add tests for it, run pnpm build and the new tests, and open a pull request that links back to the issue.",
"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 on its own branch. The diff touches the home route: +page.server.js gains the q parameter and the title filter, +page.svelte gains the search input wired to the URL, and the pagination links carry q. Beside the feature, the pull request adds the test setup the repository lacked, a vitest config and test files, listed in its own commit or clearly separated in the description.
The pull request's description says what the reviewer needs: that filtering happens in the load function because the RealWorld API has no title-search parameter, which tests cover, and that pnpm build and pnpm lint pass. The session's trajectory keeps every command run in the sandbox with its output, including the first failing lint run and the fix, so the green state is recorded rather than asserted.
Before merging, the reviewer checks that search results really are shareable by URL, that the q parameter survives pagination, that the added test tooling is scoped to what the feature needs, and that the pull request links the Linear issue it came from.
Run it on every Linear issue labeled agent
Set up the automation once in the console: a Linear trigger on linear.issue.labeled with the labels you choose, pointing at the Project whose repository the agent should work in. From then on, labeling an issue starts a run with the issue as its context, and the agent opens a pull request that links back, so triage in Linear becomes reviewable work without anyone starting it by hand.
Changes made by an app integration never fire the trigger, so an agent's own pull requests cannot label an issue into an infinite loop. The run uses the Project's repository and secrets; keep the agent label for issues described well enough to act on, and the automation's prompt tells the agent to ask on the issue when the description is not enough.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
On a laptop this issue costs a working context: clone the repo, read the load function, choose where the filter lives, add a test runner to a project that has none, run the build, open the pull request. On Rush one request does that sequence in a sandbox with the repository checked out, and the result is a pull request with the build and tests already run, recorded in the trajectory.
The proof travels with the result. The pull request links the issue, the description names the commands that passed, and the trajectory keeps their output, so review is reading a diff and a record rather than re-running everything locally. And because the trigger fires per label, a triaged backlog of well-described issues drains into pull requests one labeled issue at a time, each waiting for a human merge decision.
Frequently asked questions
Does it need a RealWorld API that supports title search?
No, and that is the point of the implementation. The load function filters the articles it already fetched by title, so the feature works against the standard RealWorld API and results stay shareable by URL because the filter runs in the server load, not in client state.
The repo has no tests. What test setup does it add?
The smallest one that covers the change: vitest with tests for the load function's q filtering, empty results and pagination, and a component test for the search input. The pull description names the new files so the added tooling is reviewable as its own concern.
Will the search box work without JavaScript?
Yes. The input is a GET form against the same route, so the query string reaches the load function on a plain navigation. The client-side enhancement only updates the URL without a full reload.
What if the issue description is ambiguous?
The automation's prompt tells the agent to ask on the issue rather than guess. A run that cannot act confidently stops with needs-you and the question, instead of opening a pull request for the wrong feature.
Can I use this for issues beyond search?
Yes. Any small, well-described issue works the same way: the label starts the run, the agent does the scoped change, adds or runs tests, builds, and opens a pull request linking back. Keep the description concrete about behaviour and acceptance, and the result is reviewable.