What the agent does
The agent turns the requested flows into a bounded test plan before clicking. In vercel/commerce, development uses pnpm install and pnpm dev; the environment must supply Shopify configuration. package.json exposes a test command that checks formatting, not customer journeys. This task therefore starts the application and tests it in an actual browser instead of presenting that command as checkout coverage. The plan lists browsing, search, product selection, cart changes and entry to checkout, with an explicit stop before placing an order.
It reads enough source to know what the browser should exercise. app/search/page.tsx takes the q and sort parameters, fetches products and renders either results or the no-match message. The product page loads a handle, returns not-found for a missing product and renders gallery and description components. The agent selects synthetic or test-catalog products and records the actual URLs and initial conditions. A successful home-page load does not stand in for testing an empty search or a product option needed before adding to cart.
The cart pass follows both optimistic feedback and persisted state. components/cart/modal.tsx creates a cart when none exists and opens when quantity increases. Its contents include quantity controls, removal and a checkout form; redirectToCheckout redirects to the provider's checkout URL. The agent tests adding a selected variant, changing quantity, removing an item and refreshing the storefront. It captures a screenshot for each meaningful step and records console or network failures relevant to a defect without copying authentication headers or customer data into the report.
It writes qa-report.md with an environment section, flow-by-flow expected and observed results, screenshot references, defects and untested paths. Each defect includes reproduction steps, impact, severity and the state needed to repeat it. Missing store credentials, unavailable catalog data or a provider refusal are named as coverage blockers rather than application bugs without evidence. The team reviews the first pass and can send a follow-up naming a missed flow after the turn finishes. The agent repeats that flow and updates the report, while leaving application code, dependencies and configuration unchanged.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Start this Next.js app in its sandbox using its declared package manager, scripts and an authorized test-store configuration. Perform a read-only browser QA pass: browse products, search with matching and no-match terms, choose product variants, add to cart, change quantity, remove an item, refresh to check persistence and start checkout. Stop before payment or order submission, and do not use real customer data or a live store. Record exact steps, expected/observed result and a screenshot for each meaningful step. Capture relevant console/network errors with credentials redacted. Write qa-report.md with environment, coverage matrix, screenshot links, defects with reproducible steps and severity, and blocked/untested flows. Finish the turn with the report so the team can request missed-flow checks in a follow-up. Change no code or dependencies and open no pull request.",
"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 result is qa-report.md and the screenshot files that support its flow records. The coverage section distinguishes completed checks, failed flows and work blocked by environment setup. A defect identifies the page, starting cart or product state, actions, expected result and observed behavior, rather than supplying only an image of an error.
The team checks the report against the agreed scope before treating it as release evidence. Reaching Shopify checkout is different from completing payment, and this request deliberately stops before an order. Read the artifact list from the session to download the report and images, and read the transcript for supporting commands. The task produces a reviewable report without editing code or claiming that every possible customer journey has been tested.
Run it on every storefront release candidate
Have your release-candidate webhook or scheduled QA job submit the repository revision and approved test-store instructions to Rush. Use a repository tree URL in resources when the candidate lives on a named branch, and record the resolved revision in the report. Your completion handler can read the session artifacts and send the report to the team's review system. A missed-flow request should continue the same session after the turn ends so the report retains its environment context.
The use case this job follows, with its automation and trigger: Steer a run as a team.
Why run it on Rush?
A browser QA pass needs a running storefront, an isolated cart and evidence that another person can inspect. Rush gives the agent its own sandbox for that work, away from an engineer's personal shopping state or current code changes. The transcript records what it started, while the report and images show which interactions it actually reached.
Independent release candidates can be checked in separate runs within your API key's concurrency limit. Their reports can keep browser state and source revision distinct, avoiding a mixed collection of screenshots from different builds. The team can request a focused follow-up when coverage is missing, rather than accepting an unsupported claim that the whole storefront passed.
Frequently asked questions
Will this QA task change code to make a flow pass?
No, the prompt forbids application and dependency changes. A failing flow belongs in the report, with enough detail for a separate fix.
Does starting checkout place a real order?
The request explicitly stops before payment or order submission and requires a test store. The report labels checkout entry separately from a completed purchase.
What happens without Shopify credentials or catalog data?
The agent records the missing setup and the flows it prevents. It must not mark checkout as passed or label every provider-configuration error an application defect.
Can the team ask it to test a flow it missed?
Yes, send the exact steps as a follow-up once the current turn finishes. Ask it to update the same report and preserve the earlier coverage results.