What the agent does
The agent opens the Jira issue through the Atlassian connection and reads all of it: summary, description, acceptance criteria, comments, the issue type and anything linked. A bug report gets its reproduction steps written down first; a story gets a list of the behaviours the criteria name. That list is what the pull request will be checked against.
Next it reads the build and the layout. In a Spring Boot app like spring-projects/spring-petclinic, pom.xml inherits spring-boot-starter-parent 4.1.0 with java.version 17, and the build runs more than tests: spring-javaformat-maven-plugin validates formatting, Checkstyle 12.3.1 runs a check goal with the nohttp rules, and JaCoCo instruments the run. The code is organised by feature, not by layer: owner/ holds OwnerController, Owner, OwnerRepository (a Spring Data repository with findByLastNameStartingWith(String lastName, Pageable pageable)), PetController, PetValidator and VisitController, with Thymeleaf views under src/main/resources/templates/owners/ and message bundles in 11 messages*.properties files. An issue such as "search owners by city" turns into a repository method, a controller change, a form field in findOwners.html and new message keys.
It writes tests the way the existing ones are written. Controller tests like OwnerControllerTests use @WebMvcTest(OwnerController.class) with @MockitoBean repositories and MockMvc, so the agent adds cases there for each criterion. I18nPropertiesSyncTest checks that the message files stay in step, so a new label added to messages.properties has to reach the other languages too, and the agent adds those keys rather than letting the test fail. PetClinicIntegrationTests boots the full app on H2 at a random port; MySqlIntegrationTests is marked @Testcontainers(disabledWithoutDocker = true) and PostgresIntegrationTests starts the postgres service from docker-compose.yml, and the agent reports which of those ran in its sandbox.
Before pushing it runs ./mvnw spring-javaformat:apply and then ./mvnw -B verify, the same command .github/workflows/maven-build.yml runs on Java 17, and fixes anything red. Then it opens the pull request with the issue key in the title and comments the link on the Jira issue.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Read Jira issue PROJ-456 through the Atlassian connection, including its description, acceptance criteria, comments and linked issues, and list the criteria. Make the change in this Spring Boot repository inside the existing feature package (owner, vet or system), extending the controller, repository and Thymeleaf templates already there. Add any new message keys to every messages*.properties file so I18nPropertiesSyncTest passes. Add @WebMvcTest cases for each criterion next to the existing controller tests, and an integration test if the change touches a repository query. Run ./mvnw spring-javaformat:apply and ./mvnw -B verify and fix what fails, and say which database integration tests ran. Open a pull request titled with the issue key that maps each criterion to a test, then comment the pull request link on the Jira issue.",
"resources": [
{
"url": "https://github.com/your-org/your-spring-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 with the Jira key in its title, and a comment on the issue that links to it. For a petclinic-shaped repository, the diff stays inside one feature package: the controller and repository under src/main/java/.../owner/ (or vet/), the template under src/main/resources/templates/, the message keys across the messages*.properties files, and new test methods in the matching *ControllerTests class, plus an integration test when a query changed.
The description lists the acceptance criteria from Jira, the test that covers each, and which integration tests ran: the H2 one always, the MySQL and PostgreSQL ones only when Docker was available in the sandbox. The session's trajectory keeps the full ./mvnw -B verify output, including the format check and Checkstyle, so a reviewer sees the same build CI will run. The repository's Maven and Gradle workflows then run on the pull request.
Before merging, a reviewer checks that a new repository method does what the issue asked against real data (a derived query name can match more than intended), that translated message keys are real translations or clearly marked for a translator, and that the controller still validates input through the existing @Valid and PetValidator path rather than a new one.
Run it on every Jira issue moved to Ready for Dev
Use a Jira automation rule with a "Send web request" action, or a Jira webhook filtered by JQL, to call your server when an issue enters the column your team uses for agent work. Your server sends this request with the issue key in input and the repository in resources. Each issue runs in its own sandbox on its own branch, so the pull requests stay independent and can be reviewed in any order.
With a webhook URL on the API key, Rush POSTs run.completed or run.failed when each turn finishes, so your server can move the issue to In Review or flag it for a person. A key runs at most max_concurrent sessions at once (4 by default); a rule that fires for a whole sprint at once should queue past that instead of retrying a 429.
The use case this job follows, with its automation and trigger: Hand off from your terminal.
Why run it on Rush?
A full ./mvnw verify on a Spring Boot app with format checks, Checkstyle, JaCoCo and database integration tests takes over the laptop while it runs, and Testcontainers needs a local Docker daemon. On Rush the agent runs that build in its own sandbox with its own clone and Maven cache, started with one request from the terminal, and it keeps going after you sign off. Your IDE, your local Docker and your checked-out branch are left alone.
The morning result is a pull request you can check rather than trust. The build output is in the trajectory, CI runs on the pull request, and the description maps each Jira criterion to a test. A team can start several issues at once, each isolated from the others, each waiting for review before anything merges.
Frequently asked questions
Will the Testcontainers integration tests run?
They run when Docker is available in the sandbox; MySqlIntegrationTests is marked disabledWithoutDocker = true, so without Docker it is skipped rather than failing. The request asks the agent to say which database tests ran, so the pull request never implies coverage it did not have. Your CI runs the rest.
Does it work with Gradle instead of Maven?
Yes. It uses the build the repository has. petclinic ships both pom.xml and build.gradle with wrappers, and the agent runs whichever the issue's change needs to keep green; name one in input if your team only uses one.
How does the agent read the Jira issue?
Through the Atlassian server in Rush's MCP catalog, which covers Jira and Confluence. Connect it once with POST /me/connections, then name it in the request's connections. The issue key goes in input; a Jira URL in resources is refused with 422 RESOURCE_UNSUPPORTED.
What if the issue is missing acceptance criteria?
It writes down the criteria it inferred from the description and comments, and puts them at the top of the pull request so a reviewer can disagree with them. If the issue is too thin to act on, it comments a question on the issue and stops; reply with a follow-up message to the same session and it continues from there.