What the agent does
The agent reads the issue before the code. resources names the repository and the Linear issue URL, which Rush reads through your Linear connection and puts in the prompt, so the description, the comments and the acceptance criteria come first.
In a Nuxt app like nuxt/movies, package.json declares Node 24 and pnpm 11.1.2 under devEngines, pins nuxt to a 4.6 nightly, vitest 4.1 with @nuxt/test-utils 4.2, @vue/test-utils and happy-dom, and @playwright/test 1.62, with scripts test:unit (vitest), test:e2e (playwright test), lint (eslint . with @antfu/eslint-config) and typecheck (nuxt typecheck). vitest.config.ts uses defineVitestConfig from @nuxt/test-utils/config and includes tests/unit/**/*.test.ts plus any *.test.ts under components/ and composables/, so tests sit next to the code: app/composables/item.nuxt.test.ts, app/components/person/Card.nuxt.test.ts, with mockMedia, mockPerson and mockImage in tests/unit/mocks.ts.
Media pages are app/pages/[type]/[id].vue, which validates type as movie or tv, awaits getMedia and getRecommendations together and renders MediaHero, MediaDetails and a CarouselBase of MediaCard; [type]/index.vue, [type]/category/[query].vue, genre/[no]/movie.vue and person/[id].vue sit beside it. The API composable is app/composables/tmdb.ts: fetchTMDB keys each request with ohash, stores the result in useState, caches the in-flight promise in an LRUCache of 500 entries for two hours and talks to the proxy at https://movies-proxy.vercel.app/tmdb, the apiBaseUrl that nuxt.config.ts also exposes in runtimeConfig.public. item.ts holds getTrailer and getVideoLink, and shared/types.ts defines Media, Person and Video.
A ticket about the details page lands in [id].vue and the media/ components; a ticket about how data is fetched lands in tmdb.ts. The agent writes the test as a *.nuxt.test.ts next to the file, using the mocks, then runs pnpm install, pnpm test:unit, pnpm lint and pnpm typecheck, the three steps of .github/workflows/tests-unit.yml, and opens the pull request with the issue URL and the results.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Implement the Linear issue given as a resource in this Nuxt codebase. Read the issue and its comments first. Make the change in the media page, component or composable it concerns, and keep the diff small. Add a Vitest test as a .nuxt.test.ts file next to the code, using the mocks in tests/unit/mocks.ts. Run `pnpm install`, `pnpm test:unit`, `pnpm lint` and `pnpm typecheck` and fix what fails. Open a pull request whose description links the issue, explains the change and quotes the test result. 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 page, component or composable it changed, and quotes the Vitest summary with the lint and typecheck results. The diff holds the change and a test beside it.
The pull request URL is on the session and in the run.completed webhook; your handler posts it on the Linear issue, since the sandbox has no Linear tools. The transcript keeps the install, the three commands and every file the agent read, so a reviewer can see that a change to caching in fetchTMDB was made after reading how useState and the LRUCache share a key.
Before merging, a reviewer checks the i18n side: strings go through $t and the 14 locale files under internationalization/, so a new label needs an en.json key, and runs pnpm test:e2e when the ticket changed what tests/e2e/homepage.spec.ts covers.
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; a label added by an app integration never fires it.
Add a linear.issue.state_changed trigger whose config.states maps a review state to plan and a later one to exec. The plan run reads the code, changes nothing and posts a plan as a comment on the issue; the exec run opens the pull request once the plan has been read.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
The movies app runs its unit tests inside a Nuxt environment through @nuxt/test-utils, on a nightly Nuxt build and pnpm 11, which is a specific toolchain to install for one ticket. On Rush the sandbox installs it from the lockfile, runs the three CI steps and is discarded, with the output kept.
The pull request quotes vitest and nuxt typecheck, and the transcript shows the agent read tmdb.ts before changing a fetch, which is how a reviewer trusts a change to caching. Tickets run in parallel, each in its own sandbox, while nobody's local node_modules is touched.
Frequently asked questions
How does the run get the Linear issue?
From a resources entry with the issue URL, read through your Linear connection and placed in the prompt before the run starts. Connect Linear once with POST /me/connections {"type": "app", "name": "linear"} and finish the sign-in it returns.
Does it comment on the issue?
No. A Linear sign-in cannot yet be named in a run's connections. The pull request URL comes back on the session and in the webhook, and your handler posts it.
Does the run call TMDB?
Through the proxy in nuxt.config.ts, https://movies-proxy.vercel.app, and only if a command does; the unit tests use the mocks in tests/unit/mocks.ts. The proxy/ folder holds the Nitro app behind that URL for anyone who runs their own.
Will it run the Playwright tests?
Only when asked. tests/e2e/homepage.spec.ts runs under pnpm test:e2e in .github/workflows/tests-e2e.yml; add it to the prompt for a ticket that changes the home page.