What the agent does
The agent clones the repository into its own cloud sandbox and reads the issue next to the code. Take a feature request against a Spring Boot app like spring-projects/spring-petclinic: "Record which vet saw the pet on each visit, choose the vet on the new-visit form, and show the vet in the owner's visit history." It starts with pom.xml: spring-boot-starter-parent 4.1.0 and Java 17, with a Gradle build beside it and two CI workflows, maven-build.yml running ./mvnw -B verify and gradle-build.yml running ./gradlew build.
Then it reads the owner package, where visits live. Visit.java maps the visits table with a visit_date and a @NotBlank description. VisitController serves GET and POST /owners/{ownerId}/pets/{petId}/visits/new, and its @ModelAttribute("visit") method loadPetWithVisit loads the owner and pet before each handler. The form is templates/pets/createOrUpdateVisitForm.html and the history renders in templates/owners/ownerDetails.html. Vets are a separate package, vet/, with Vet, Specialty and VetRepository.
The schema is not generated: application.properties sets spring.jpa.hibernate.ddl-auto=none and loads db/${database}/schema.sql and data.sql, with database=h2 by default. There are three schema files, for H2, MySQL and PostgreSQL, and today's visits table has id, pet_id, visit_date and description. A vet on a visit means a vet_id column and foreign key in all three, and seed data that still loads.
Last it reads the tests to plan in their style. VisitControllerTests is a @WebMvcTest(VisitController.class) with the owner repository as a @MockitoBean; PetClinicIntegrationTests boots the whole app on H2, and MySqlIntegrationTests and PostgresIntegrationTests run against containers. The plan lists the JUnit tests to add at each level: the form offers the vets, posting a visit with a vet saves it, a missing vet is rejected or allowed as the author decides, and the owner page shows the vet's name.
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 owner and visit controllers. Change no code. Reply with an implementation plan: the files to change with the reason for each, the JUnit 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: the session read returns it as result, and a run started by a Linear state mapped to plan posts it as a comment on the issue. For the vet-on-visit example its file list covers Visit.java, VisitController.java, the visit form and owner details templates, the three schema.sql files and their data.sql, the message bundles for the new label, and the controller and integration tests, each with the reason it changes.
The risks are specific to how PetClinic is built. The schema exists three times and the MySQL and PostgreSQL copies are only exercised by the container tests, so a typo there passes the default build. VisitControllerTests mocks the owner repository, so it needs a vet source too. Open questions go to the author: is the vet required, may it be any vet or only one with a matching specialty, and should existing visits be backfilled or left empty.
No code is changed and nothing is pushed. The session's record lists every file the agent opened and any command it ran, such as a ./mvnw -B verify to confirm today's build, so the plan's statements can be checked against what was actually read.
Run it on every Linear issue moved to Planning
In the console, add an automation with a Linear trigger on linear.issue.state_changed and a states entry mapping Planning to plan. Each issue moved into Planning starts a read-only run that comments its plan on the issue through the runner's Linear connection. Mapping a later state to exec lets the same issue start the build once the plan is agreed.
Without the automation, a service of your own can send this request with the issue's URL in resources and read the plan from the session's result when the run.completed webhook arrives.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
A Spring Boot plan has to account for what the framework hides: SQL init files instead of generated schema, a model attribute method that runs before every handler, sliced tests that mock repositories. On Rush the agent reads all of it in its own sandbox, can run the Maven build to see today's state, and keeps every file read and command on the session as evidence for the plan.
Each issue moved into Planning gets its own run, in parallel, so a backlog can be planned in one pass and the authors answer the open questions on the issues before anyone opens an IDE.
Frequently asked questions
My app uses Flyway or Liquibase instead of schema.sql. Does the plan change?
Yes. The agent reads how your schema is managed and plans a migration in that tool, naming the version file to add. PetClinic loads schema.sql per database, so its plan edits those three files instead.
Will it build my project during a plan run?
It can, with the wrapper the repository ships (./mvnw or ./gradlew), to confirm how the code compiles and which tests pass today. A plan run changes no code, so the build is the same afterwards.
Does it plan tests at the right level?
It reads the existing tests and follows them: @WebMvcTest slices for controller behavior, @SpringBootTest for the full app, container tests for database-specific SQL. The plan says which new case belongs at which level.
Can several people's issues be planned at once?
Yes. Each state change starts its own run in its own sandbox, and each plan lands on its own issue.