What the agent does
First the agent reads the Asana task you name through the Asana connection: title, description, subtasks and comments. It turns that into a short list of acceptance criteria and keeps it for the pull request, so "show the last ten team events on the dashboard" becomes checks it can test, such as which events, in what order, and what an empty team sees.
Then it maps the task onto the app. In a Next.js app like nextjs/saas-starter that means the App Router tree: the dashboard pages under app/(dashboard)/dashboard/ (general, activity, security), the sign-in and team server actions in app/(login)/actions.ts, the route handlers under app/api/, and the data layer in lib/db/. A task about team activity, for example, leads it to the activityLogs table and the ActivityType enum in lib/db/schema.ts, getActivityLogs in lib/db/queries.ts, and the validatedActionWithUser wrapper in lib/auth/middleware.ts that every authenticated action goes through. It extends those instead of adding parallel ones.
The starter has no test runner and no test script, only dev, build, start and the db:* scripts, so "with tests" is a decision the agent makes visibly. It adds the smallest setup that can test what the task changed (Vitest for a query or a server action's validation, for instance) with a test script, and says in the pull request that the runner is new. A schema change goes through Drizzle: it edits lib/db/schema.ts, runs pnpm db:generate to write a migration next to 0000_soft_the_anarchist.sql, and applies it to a throwaway Postgres in its sandbox with pnpm db:migrate.
Before opening the pull request it installs with pnpm install --frozen-lockfile against pnpm-lock.yaml, runs the new tests, pnpm exec tsc --noEmit and pnpm build, and fixes what fails. Then it opens the pull request and adds a comment on the Asana task with the link and a one-line summary. Anything it could not settle from the task, such as copy or a design choice, goes in that comment as a question.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Read the Asana task https://app.asana.com/0/<project-id>/<task-id> through the Asana connection, including subtasks and comments, and write down its acceptance criteria. Implement it in this Next.js repository, extending the existing pages, server actions in app/(login)/actions.ts and queries in lib/db/queries.ts rather than adding parallel ones. If the task changes the schema, edit lib/db/schema.ts and generate the migration with pnpm db:generate. Add tests for the behaviour it changes; if the repository has no test runner, add Vitest with a test script and say so in the pull request. Run pnpm install --frozen-lockfile, the tests, pnpm exec tsc --noEmit and pnpm build, and fix what fails. Open a pull request that links the task and maps each criterion to a test, then comment on the Asana task with the pull request link and a one-line summary.",
"resources": [
{
"url": "https://github.com/your-org/your-nextjs-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 and a comment on the task. For a task in a repository shaped like saas-starter, the diff typically touches a page or component under app/(dashboard)/, an action in app/(login)/actions.ts or a handler under app/api/, a query in lib/db/queries.ts, and, when the schema changed, lib/db/schema.ts plus a new SQL file and journal entry under lib/db/migrations/. If the test runner was added, package.json, pnpm-lock.yaml, a config file and the first test files are in the diff too, called out in the description.
The description links the Asana task and lists each acceptance criterion beside the test that checks it. The session's trajectory keeps each command the agent ran with its output: the install, the migration applied to a fresh database, the test run, the type check and the production build. If the repository has CI or a preview deployment on pull requests, those run as usual.
Before merging, a reviewer checks the migration SQL (Drizzle writes it, but a person should read a schema change), checks that new server actions go through validatedActionWithUser so they cannot run signed out, and decides whether to keep the test runner the agent added. The comment on the task means the person who filed it sees the pull request without being told.
Run it on every Asana task assigned to the agent
Add a custom field your team sets to hand a task to the agent, register an Asana webhook on the project, and have your server send this request when that field changes, with the task URL in input and the repository in resources. Each task runs in its own sandbox on its own branch, so tasks handed off together come back as separate pull requests.
Give the API key a webhook URL and Rush POSTs run.completed or run.failed when each turn finishes, with the session_url and the final answer, so your server can update the task's status field as well. Send an Idempotency-Key per task so an Asana webhook delivered twice starts one run, not two.
The use case this job follows, with its automation and trigger: Hand off from your terminal.
Why run it on Rush?
On a laptop, an Asana task in a Next.js app means a local Postgres, an .env with POSTGRES_URL, AUTH_SECRET and Stripe keys, pnpm dev running, and the branch checked out until you are done. On Rush the agent gets its own sandbox with its own clone and its own throwaway database, generates and applies the migration there, and builds the app, while your working copy stays on whatever you were doing.
The work comes back with proof attached. The pull request carries the tests and the build, the trajectory shows every command and its output, and the Asana comment links the task to the change. Several tasks can run at once, each on its own branch, each with a pull request a person reviews.
Frequently asked questions
Does the agent need my Stripe or database credentials?
Not for most tasks. It runs Postgres in its sandbox for migrations and uses placeholder values for build-time variables like STRIPE_SECRET_KEY. If a task really needs a secret, save it in a Rush Project with POST /o/{org}/secrets and start the session in that Project; the agent reads it as an environment variable and the value never appears in the pull request.
My repository has no tests. Will it add a test framework without asking?
The request on this page tells it to add Vitest when there is no runner and to say so in the pull request, because a task done "with tests" needs somewhere to put them. If you would rather choose the framework, name it in input, or tell it to skip tests and describe what it checked by hand.
How does the run read and comment on the Asana task?
Connect Asana once with POST /me/connections and name it in the request's connections. Asana is in Rush's MCP catalog, and the agent uses its tools to read the task and add the comment. A key run gets only the connections it names.
Can I start this from my terminal?
Yes. It is one curl -X POST https://api.prix.dev/o/$ORG/sessions with your API key and this body. The answer is 202 with an execution_id, and you can close the terminal: the run keeps going, and the session read, the event stream or the webhook tells you when the pull request is up.