What the agent does
The agent starts from the Linear issue and the repository in its own sandbox, and mirrors how existing page types are built. In a site like wagtail/bakerydemo (Django >=6.0,<6.1, Wagtail >=8.0,<8.1, Python 3.12.1 per runtime.txt), LocationsIndexPage in bakerydemo/locations/models.py sets subpage_types = ["LocationPage"], and LocationPage uses a StreamField(BaseStreamBlock()) from bakerydemo/base/blocks.py plus address fields. Tests today are thin: bakerydemo/base/tests/test_home_page.py and test_seo.py. There is no workshop page type.
It adds a WorkshopPage model with a date, a price and a session schedule as StreamField blocks (StructBlocks for session title/time or reusing patterns from BaseStreamBlock), sets parent_page_types / updates LocationsIndexPage.subpage_types so workshops are allowed under the locations index, creates a template under bakerydemo/templates/ and generates a migration. It registers panels so editors can fill the fields in the Wagtail admin.
It adds tests that create a locations index and a workshop child, assert the new fields and that an disallowed parent rejects the page type. It runs python manage.py test with the project's test settings (bakerydemo/settings/test.py), applying migrations in the sandbox first if needed.
Last, it opens a pull request that links the Linear issue, lists the model, migration, template and tests, and points at the manage.py test transcript.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Linear issue labeled agent says: \"Add a New Page Type to a Wagtail Site. Add a WorkshopPage with a date, a price and a session schedule as StreamField blocks, allowed under the locations index, with a template and a migration.\" Do the work in this repository, add tests for it, run python manage.py test, and open a pull request that links back to the issue.",
"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
What comes back is a pull request on its own branch. The description shows WorkshopPage fields, the StreamField schedule blocks, the subpage_types update on LocationsIndexPage and the migration name. The Linear issue is linked.
The transcript keeps python manage.py test (and migrate if run) with full output. An invalid subpage_types string or missing template fails there before review.
Before merging, a reviewer checks money/date field types, that only the locations index can parent workshops if that was the rule, that the template extends the site base and that tests fail if WorkshopPage is removed from subpage_types.
Run it on every Linear issue labelled agent
In the console, an automation with a linear trigger on linear.issue.labeled and the label agent starts one run per labelled issue, with the issue as its context, in the Project's repository. Changes made by an app integration never fire it, so the agent's own updates do not start new runs.
From your own server, the same run is one POST /o/{org}/sessions per issue: put the repository in resources, and add the issue's https://linear.app/<workspace>/issue/<ID> URL there too to have Rush read it through your Linear connection into the prompt. A webhook on the API key posts run.completed or run.failed when the turn finishes, with the session_url to read the result.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
Wagtail page types need a migration, template and parent rules that only show up when Django's test database runs. In a Rush sandbox the agent applies migrations and runs python manage.py test in isolation, so a broken StreamField definition does not touch a shared demo database.
A Linear label becomes a CMS content-model PR with proof. Several Wagtail page-type issues can run in parallel sandboxes under the key's max_concurrent limit, each with its own branch and transcript.
Frequently asked questions
Will LocationPage still be the only child of the index?
No after this change: LocationsIndexPage.subpage_types gains WorkshopPage (and keeps LocationPage unless the issue says otherwise). The PR shows the exact list.
Where do the StreamField blocks live?
Usually next to BaseStreamBlock in bakerydemo/base/blocks.py, or a dedicated workshops blocks module imported by the page. The agent prefers extending the existing blocks module when the schedule blocks are small.
Does it load demo workshop content?
Only if tests need fixtures. It does not bulk-import CMS content into production; migrations define schema, and tests create pages in the test database.
Which Python version?
Whatever the repo pins. Bakery demo's runtime.txt names python-3.12.1; the agent uses that line when choosing the sandbox interpreter.