What the agent does
The agent reads the existing movie view before adding another page. In nuxt/movies, app/pages/[type]/[id].vue validates movie or TV routes, loads media and recommendations, then renders MediaHero, MediaDetails and recommendation MediaCard components. app/components/media/Card.vue accepts a Media item and type, displays its poster and rating, and wraps the card in a NuxtLink. The watchlist should reuse that card rather than duplicating its image and navigation markup.
shared/types.ts defines the media fields and the movie/TV distinction. The agent chooses a small persisted representation sufficient to render the requested movie cards and defines stable identity for add, remove and duplicate prevention. It adds a shared watchlist state path and app/pages/watchlist.vue, with a clear empty state and an accessible remove control. Since the card itself is a link, the new action must avoid nesting another interactive control inside that link.
The feature restores localStorage only in the browser and keeps server rendering free of browser globals. It defines the first client render so a stored list does not create a hydration mismatch, and makes repeated clicks idempotent. Removal updates the current list and the saved entry; a reload confirms persistence. The issue asks for a visitor's local watchlist, so the task does not add accounts, a database or a server route that implies cross-device synchronization.
package.json specifies a Node runtime of ^24.0.0 and pnpm 11.1.2, with lint, typecheck, build and test:unit scripts. The existing app/components/person/Card.nuxt.test.ts uses mountSuspended from Nuxt test utilities, and app/composables/item.nuxt.test.ts shows composable tests. The agent adds watchlist coverage using that structure, runs pnpm test:unit --run, pnpm lint, pnpm typecheck and pnpm build, and separates any external movie-proxy failure from a local persistence failure.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "A Linear issue labeled agent asks for a visitor watchlist in our Nuxt movie app: add/remove movies, persist the list in localStorage and render /watchlist using the existing media card. Read the media detail page, card, shared Media type and existing Nuxt tests. Keep a single shared watchlist state path with stable movie identity and duplicate prevention. Avoid browser storage during SSR, define hydration behavior and provide an empty state and accessible remove action without nesting buttons inside the card's NuxtLink. Do not add accounts or a backend. Test add/remove, repeat clicks, reload restoration and a server render without localStorage. Run pnpm test:unit --run, pnpm lint, pnpm typecheck and pnpm build using the repository's declared runtime. Open a pull request linking the supplied Linear issue and list actual test/build results, including external-service limits.",
"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
The PR adds the watchlist page, a shared state implementation and the add/remove controls, with tests for persistence and rendering. It reuses MediaCard and retains its poster, rating and detail-page behavior. Its description names the browser-storage format, how duplicate movies are handled and when saved entries become visible. New copy follows the app's existing translation setup instead of leaving an unrelated language island in the new page.
A reviewer adds a movie, navigates to the watchlist, reloads and removes it. Empty-state behavior and keyboard access receive the same attention as the populated list. The PR includes unit, lint, type-check and build results without presenting a successful build as proof of browser storage. If a movie service is unavailable, the answer identifies that dependency and the checks it prevented, rather than reporting an unverified end-to-end result.
Run it on every Linear issue labelled watchlist
Your Linear webhook handler selects the issue and passes its body and URL in the request's string input, together with the app repository as a resource. Call the sessions API with an API key after the Rush GitHub App can access that repository. Use a stable idempotency header for retries, and keep the issue's storage policy explicit. A request for local browser persistence should not quietly turn into a database-backed collection feature.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
A watchlist crosses page rendering, shared browser state and client hydration. Rush gives the agent its own sandbox for the Nuxt build and tests, leaving your local app and browser collection untouched. The result is a reviewable implementation with command output, rather than disconnected snippets for a composable and a page that nobody has checked together.
The same API can start independent work on several Nuxt repositories, each with its own session and PR. Their transcripts expose different card interfaces, runtime requirements and test results instead of hiding them behind a generic storage implementation. When a turn finishes, you can send a follow-up about saved-entry behavior and resume the existing sandbox with the relevant files and investigation still in place.
Frequently asked questions
Does the watchlist sync between devices?
This issue requests localStorage, so the saved list belongs to the browser where it is created. Cross-device sync needs an account and server persistence design outside this task. The PR should describe the local scope plainly.
Will it reuse the existing movie cards?
Yes, the prompt names app/components/media/Card.vue as the existing rendering surface. Its NuxtLink wrapper affects where add/remove controls can be placed. Tests should verify card navigation as well as the watchlist action.
How are duplicate movies handled?
The implementation must choose stable movie identity and make repeated adds leave a single entry. Tests cover that policy and removal followed by reload. If the issue later includes TV shows, identity needs to preserve the movie/TV distinction already present in the shared types.
Does localStorage break server rendering?
Direct browser-storage access during server rendering would be a problem, so restoration belongs on the client. The task requests both a server-render check and reload coverage. The PR explains when saved content appears and how it avoids hydration mismatches.