# Redesign a Page in a Next.js App with Your Team

Yes. The agent redesigns the page in its own sandbox, saves a screenshot after each pass, waits for your team's follow-ups, and opens the pull request once approved.

[Run this on Rush](https://cloud.getrush.ai/run/redesign-page/nextjs/), in a Project that has your repository.

## What the agent does

The agent reads the page and the design system it must stay inside. In an app like nextjs/saas-starter the pricing page is `app/(dashboard)/pricing/page.tsx`, a server component with `revalidate = 3600` that calls `getStripePrices()` and `getStripeProducts()` from `lib/payments/stripe.ts`, finds the `Base` and `Plus` products, falls back to 800 and 1200 cents and a 7-day trial when Stripe returns nothing, and renders two `PricingCard`s whose `<form action={checkoutAction}>` posts a hidden `priceId` to the server action in `lib/payments/actions.ts`; the button is `pricing/submit-button.tsx`, a client component on `useFormStatus`. The tokens are in `app/globals.css` (Tailwind 4 `@theme` with `--color-primary`, `--color-muted-foreground`, `--color-card`, `--radius-*`) and the components in `components/ui/` are shadcn/ui's new-york set: `button` with its `default`, `outline`, `secondary`, `ghost` and `link` variants, `card`, `input`, `label`, `radio-group`, `avatar`, `dropdown-menu`. The current page uses `text-gray-900` and `text-orange-500` directly rather than those tokens, which is the first thing a redesign fixes.

To see the page it needs the app running. `pnpm install`, a Postgres in the sandbox so `lib/db/drizzle.ts` finds `POSTGRES_URL` at import time, and a Stripe test key stored as a Project secret under `STRIPE_SECRET_KEY`, because `stripe.prices.list` runs when the page renders; without a key the agent says so and works against the fallback prices by stubbing the two Stripe calls locally for the duration of the run. Then `pnpm dev` and the agent's browser on `localhost:3000/pricing`, where it saves the first screenshot as an artifact and writes a short note of what it plans to change: a `Card`-based layout, the tokens instead of raw gray and orange classes, a feature list with consistent icons, the recommended plan marked, the trial line made legible, and the button variant chosen from `buttonVariants`.

The work happens in passes, each ending the agent's turn. A pass changes `pricing/page.tsx` (and `submit-button.tsx` if the button changes), rebuilds, screenshots at desktop and mobile widths, and stops with a message that lists what changed and what it would do next. The sandbox parks with its disk and memory, so a follow-up from the run's starter or an org admin wakes it where it was: `POST /o/{org}/sessions/{id}/messages` with `{"input": "..."}`, the same way the console sends it. Anyone in the org can read the transcript and the screenshots as the run works; the people who can steer are the starter and admins, and one of them can take the browser on a five-minute lease to point at an element directly.

The last follow-up says the design is approved. Only then does the agent run `pnpm build` and `npx tsc --noEmit`, confirm the `checkoutAction` form still posts the right `priceId` for each plan, and open the pull request. Until that message arrives it does not open one, even if a pass looks finished to it.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Redesign the pricing page of this app to be clearer, keeping the existing design tokens in app/globals.css and the components in components/ui. Start the app with a local Postgres and the STRIPE_SECRET_KEY secret if present; if there is no key, stub the two Stripe calls for this run and say so. Work in passes: after each pass save screenshots of the page at desktop and mobile widths as artifacts, write what changed and what you propose next, and end your turn. Wait for a follow-up before the next pass. Do not open the pull request until a follow-up says the design is approved; then run pnpm build and tsc --noEmit, confirm each plan's form still posts its priceId to checkoutAction, and open it with the final screenshots in the description.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

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

What comes back, after the approving follow-up, is a pull request on a new branch that changes `app/(dashboard)/pricing/page.tsx` and possibly `pricing/submit-button.tsx`, uses `Card` and the token classes from `globals.css` in place of raw color utilities, and leaves `lib/payments/`, the server action and the Stripe calls as they were. Before that, the session's artifacts hold one pair of screenshots per pass, so the team can scroll the history of the design in the console.

The description embeds the final desktop and mobile screenshots, lists each pass and the follow-up that steered it, and quotes `pnpm build` and `tsc --noEmit`. The transcript shows each follow-up as its own turn with the changes it caused.

Before merging, a reviewer checks that both forms still carry the right hidden `priceId`, that the page still exports `revalidate`, that nothing moved into a client component that needs server-only data, and that the markup still reads correctly without JavaScript since the form posts to a server action.

## Run it on every design issue moved to In review

Create an automation in the Project with this prompt and a `linear` trigger on `linear.issue.state_changed`, with `config.states` mapping your design review state to `exec`. Moving a page redesign ticket into that state starts a run with the ticket's description as the brief, and the designer and the engineer steer it from the console with follow-ups until the pull request opens.

Add a `webhook` URL to the API key so `run.completed` arrives after each turn, and have a handler on your server post the new screenshots' artifact links to the channel where the design is being discussed; each turn's result includes the session URL to read the full transcript.

## Why run it on Rush?

A redesign over a screen share means one person drives and everyone else waits. On Rush the page runs in a sandbox any org member can read, the screenshots are artifacts with URLs, and the people allowed to steer send follow-ups whenever they have looked, in their own time, without a laptop being held open. The run parks between turns and costs nothing while it waits.

Because the pull request opens only after the approving message, nothing half-finished reaches the repository, and the record shows exactly which follow-up asked for which change. The same flow works for the landing page, the dashboard or any other route in the app.

## Frequently asked questions

### Who can send the follow-ups?

The run's starter and org admins. Everyone in the org can open the run and read its transcript and screenshots as it works. A follow-up sent while a turn is still running is refused with `409 TURN_ACTIVE`, so send it once the status leaves `running`; the console queues it for you.

### Does the agent need a real Stripe key?

To render real prices, yes, as a Project secret named `STRIPE_SECRET_KEY`, in test mode. Without one the page would throw when `stripe.prices.list` runs, so the agent stubs the two Stripe calls for the run and says so; the design work is the same either way.

### Can I point at what to change instead of describing it?

Yes. The run's starter or an admin can take control of the sandbox browser on a five-minute lease that one person holds at a time, then hand it back with a follow-up explaining what they showed.

### Will it change the design tokens or the shared components?

No. The prompt keeps `app/globals.css` and `components/ui/` as they are, so the pricing page comes to match the system rather than the system moving to match the page. If a token is missing, the agent says so in its pass notes and asks.

### How long does the run wait for a follow-up?

A parked sandbox is kept for seven idle days, so a review that spans a weekend picks up where it left off. After that the run is gone and a new one starts from the branch it pushed.