What the agent does
The agent clones the repository into its own cloud sandbox and reads before it writes a word of the plan. Take a feature request against a Wagtail site like wagtail/bakerydemo: "Let visitors narrow search results to one section of the site, such as the blog, the breads or the locations." The agent reads requirements/base.txt (Django 6.0 and Wagtail 8.0), then the repository's own AGENTS.md, which lists the apps under bakerydemo/ and says to run ./manage.py test with DJANGO_SETTINGS_MODULE=bakerydemo.settings.test for render tests.
The search view is where the request lands, and it has two paths. bakerydemo/search/views.py checks whether WAGTAILSEARCH_BACKENDS["default"]["BACKEND"] contains elasticsearch. If it does, as settings/production.py configures it, the view runs one Page.objects.live().search(query). If not, it searches BlogPage, BreadPage, LocationPage and RecipePage one by one, collects their page_ptr ids and filters Page by them. A section filter has to work in both branches, and the agent reads the four models' search_fields (for example introduction, subtitle and body on BlogPage) to see what each section already indexes.
It also reads what renders the results and what tests exist. templates/search/search_results.html already branches on result.specific.content_type.model to label each result by its page type, so the section is already known per result. The view paginates ten per page with Django's Paginator, which a filter parameter must survive. Tests live in bakerydemo/base/tests/, built on Wagtail's WagtailPageTestCase with a page tree and Site created in setUpTestData, and settings/test.py uses a local-memory cache and MD5 password hashing to stay fast.
The plan it writes lists the files to change and why (search/views.py, the results template, possibly urls.py if the section becomes a path rather than a query parameter), the Django TestCase tests to add (each section returns only its pages, an unknown section is ignored or rejected, pagination keeps the filter), the risks, and the open questions for the issue's author.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Read the Linear issue in this run's resources and the code it touches in the page models and search view. Change no code. Reply with an implementation plan: the files to change with the reason for each, the Django TestCase tests to add, the risks, and the open questions for the author.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
},
{
"url": "https://linear.app/your-workspace/issue/ENG-42"
}
]
}- 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 the plan as the run's answer, which the session read returns as result; started by the Linear state trigger, the same plan is posted as a comment on the issue. It has the four parts the prompt names, and each file entry carries its reason, so the engineer who builds it knows why search/views.py changes in two places instead of one.
The risks section is where this codebase is unusual. Search behaves differently in production (Elasticsearch through settings/production.py) and in development and tests (the database backend), so tests that pass locally exercise only one branch. The plan says so and proposes how to cover the other, such as a test that overrides WAGTAILSEARCH_BACKENDS. Open questions include whether PersonPage and the gallery should be searchable sections too, and whether the filter belongs in the URL path for caching.
No code changes and no branch. The session keeps every file the agent opened and every command it ran, including any ./manage.py test run it used to confirm today's behavior, so each line of the plan can be traced to what it read.
Run it on every Linear issue moved to Planning
Give the Project an automation with a Linear trigger on linear.issue.state_changed whose states map Planning to plan. Moving an issue into Planning starts a read-only run that posts the plan as a comment on the issue through the runner's Linear connection. Map the next state to exec and moving the issue on starts the build.
Called from your own code instead, this request returns the plan as the session's result, and a webhook on the API key tells you when it is ready.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
The interesting facts in this plan come from reading settings and templates as well as views, and from noticing that production and tests take different code paths. On Rush the agent reads the whole repository in its own sandbox, can run the Django test suite to see today's behavior, and leaves every file read and command on the session as evidence.
Plans also run in parallel. Each issue moved into Planning gets its own run, so a sprint's worth of feature requests can be planned while the team works, and the plans arrive on the issues ready for the authors to answer.
Frequently asked questions
Does it understand Wagtail, or only plain Django?
It reads what the code uses. In a Wagtail project it reads the page models, their search_fields, Page.objects.live() and Wagtail's test helpers, and plans in those terms; in a plain Django project it plans around your models, views and forms.
Will it run my tests?
It may run them to confirm how the code behaves today, using the command the repository documents, here ./manage.py test with the test settings. A plan run changes no code, so the suite is the same before and after.
Where does the plan go?
Started by a Linear state mapped to plan, it is posted as a comment on the issue. Started from the API, it is the session's result, which you can post wherever your team discusses work.
Can I ask it to plan against a branch instead of the default branch?
Yes. Use the repository's /tree/<branch> URL in resources and the run clones that branch. The plan then reflects the code on that branch, including work not merged yet.