What the agent does
The agent starts from the Linear issue and the repository in its own sandbox, and maps how owners are exposed today. In a codebase like spring-projects/spring-petclinic (Spring Boot 4.1.0 parent, Java 17, Maven wrapper ./mvnw), OwnerController is an MVC @Controller that serves Thymeleaf under /owners, /owners/find and /owners/{ownerId}, backed by OwnerRepository (JpaRepository<Owner, Integer> with findByLastNameStartingWith). JSON today is limited: VetController exposes a @ResponseBody vet list, not owners. There is no /api/owners resource.
It adds a dedicated REST controller (for example OwnerRestController) mapped under /api/owners for listing, reading and creating owners with their pets, reusing Owner, pet associations and bean validation already on the domain. Validation failures return Spring's problem details (application/problem+json) rather than HTML form errors. It keeps the existing Thymeleaf owner flows untouched so the browser UI and the API do not fight over the same request mappings.
Tests go under src/test/java/.../owner/ beside OwnerControllerTests and OwnerTests, using MockMvc or @WebMvcTest/@SpringBootTest in the style the project already uses. Cases cover list and get JSON shapes, a successful create, and a validation error that answers a problem detail with field errors. The agent runs ./mvnw verify, which is the project's full Maven lifecycle including tests.
Last, it opens a pull request that links the Linear issue, lists the new controller, any DTO or exception-handler wiring and the tests, and quotes the verify command result from the sandbox.
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 REST API to a Spring Boot App. Add JSON endpoints under /api/owners for listing, reading and creating owners with their pets, with validation errors returned as problem details.\" Do the work in this repository, add tests for it, run ./mvnw verify, 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 states that owners were HTML-only through OwnerController while vets already had a JSON peek, then shows the new /api/owners endpoints and problem-detail error bodies. The Linear issue is linked.
The transcript keeps ./mvnw verify (downloads, compile, tests) with full output. PetClinic's existing unit and integration tests stay part of that run, so a broken Owner mapping fails the same way CI would.
Before merging, a reviewer checks content types, that create validates required owner fields, that pets nest as the API promises, that Thymeleaf /owners routes still render, and that the new tests fail if the REST controller is missing.
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?
PetClinic's verify step pulls dependencies and runs a modest but real suite, including database-backed integration tests. In a Rush sandbox that work happens on an isolated disk with the project's mvnw, so nobody's laptop JDK or local MySQL/Postgres profile is required for the agent to finish.
Labelling the issue in Linear yields a PR whose transcript shows the agent reading OwnerController and OwnerRepository before adding a parallel REST surface. Multiple Spring issues can run concurrently, each in its own sandbox and branch, up to the key's max_concurrent limit.
Frequently asked questions
Does it replace the Thymeleaf owner pages?
No. The issue asks for JSON under /api/owners. The existing /owners MVC controller stays; the agent adds a separate REST mapping so the browser UI keeps working.
Maven or Gradle?
Whatever the repo's canonical wrapper is. PetClinic ships both; the prompt pins ./mvnw verify, so the agent uses the Maven wrapper unless your Project prompt says otherwise.
What does a validation error look like?
A problem details response (application/problem+json) with the failing fields, not a Thymeleaf form re-render. Tests assert status and content type for that path.
Will it expose every Owner field?
It mirrors what create/edit already need (name, address, city, telephone, pets) and says in the PR if it omitted internal fields. Reviewers can tighten the DTO before merge.