What the agent does
The agent reads how the repository is assembled before it reads the diff, because quarkusio/quarkus-quickstarts is one aggregator over about a hundred independent builds. The root pom.xml is io.quarkus.quickstarts:quickstart-projects, packaging pom, listing every quickstart as a module and adding the build-reporter-maven-extension and an incremental profile with gitflow-incremental-builder 4.6.0 that builds only what changed against HEAD. Each quickstart has its own mvnw, its own pom.xml importing io.quarkus.platform:quarkus-bom at 3.40.1.1, maven.compiler.source and target at 17, maven-surefire-plugin 3.5.4 with java.util.logging.manager set to org.jboss.logmanager.LogManager, and a native profile that turns on quarkus.native.enabled, turns off quarkus.package.jar.enabled and binds maven-failsafe-plugin to integration-test and verify. The agent runs ./mvnw verify inside each touched quickstart rather than at the root, which is what the CI does per module and what a reader of the quickstart would do.
CONTRIBUTING.md sets the rules the review applies: pull requests target the development branch and main is reset on each release, every quickstart must have unit tests, every quickstart that supports native mode must have native tests, a pull request that depends on an unmerged Quarkus feature carries [DO NOT MERGE] in its title, and a new quickstart must be listed in README.md. .github/workflows/build-pr-development.yml runs on JDK 21, fails if git grep finds a star import in any .java file outside .mvn and the two markdown files, clones and builds Quarkus main when the base is development, then runs ./mvnw -e -B -fae --settings .github/mvn-settings.xml clean install -Dstart-containers and uploads target/*-reports/TEST-*.xml on failure. The agent runs the star-import check verbatim and uses the same settings file, which points Maven at a Central mirror.
The test shape is read from the quickstarts themselves. getting-started/src/test/java/org/acme/getting/started/GreetingResourceTest.java is a @QuarkusTest using REST-assured's given().when().get("/hello").then().statusCode(200), and GreetingResourceIT extends it with @QuarkusIntegrationTest so the native profile runs the same cases against the built runner. hibernate-orm-panache-quickstart depends on quarkus-hibernate-orm-panache, quarkus-rest-jackson and quarkus-jdbc-postgresql, sets only %prod datasource properties plus quarkus.hibernate-orm.sql-load-script=import.sql, and its FruitsEndpointTest lists, deletes and re-lists fruits through both /entity/fruits and /repository/fruits. With no %test datasource configured, Quarkus Dev Services supplies the test database by starting a container, so the agent checks whether the sandbox can start one before counting a database test as run, and says so in the review when it cannot.
The diff is then read with the three questions the prompt names. CDI scopes: FruitEntityResource is @ApplicationScoped with @Transactional on create, update and delete and not on the two reads, so a new resource that holds request state in a field, or a write method without @Transactional, is a finding. Reactive versus blocking: a quickstart on quarkus-rest and quarkus-hibernate-orm-panache runs its endpoints on worker threads, while the hibernate-reactive-* and getting-started-reactive quickstarts return Uni and must not block, so a Thread.sleep, a JDBC call or a .await() inside one of those is blocking. Panache queries: the entity pattern in FruitEntity uses listAll(Sort.by("name")), findById and persist, and the repository pattern injects FruitRepository, an empty PanacheRepository<Fruit>, and calls listAll, findById, persist and delete on it from FruitRepositoryResource; a hand-written HQL string that concatenates request input, or a findById whose null result is not turned into a 404 as getSingle does, gets a finding with the line. One GitHub review is posted per run, quoting the surefire summary for each touched quickstart, separating blocking issues from suggestions, with file and line on every finding. The agent pushes nothing.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Review this pull request on a Quarkus quickstart repository. Read CONTRIBUTING.md first. Check the branch out, confirm it targets development, run the star-import check from .github/workflows/build-pr-development.yml, and in each quickstart the diff touches run ./mvnw -e -B --settings ../.github/mvn-settings.xml verify. If a touched quickstart's tests need Dev Services and the sandbox cannot start a container, say so rather than skipping silently. Read the diff with the resource classes, the entities or repositories, application.properties and the test classes. Look for beans whose scope does not fit the state they hold, write paths without @Transactional, blocking calls inside endpoints that return Uni or Multi, Panache queries built from unvalidated request input, findById results not mapped to 404, a new quickstart missing unit tests, native tests or its README.md entry, and star imports. Post one GitHub review that quotes each quickstart's surefire and failsafe summary, separates blocking issues from suggestions, and cites file and line for every finding. Do not push commits.",
"resources": [
{
"url": "https://github.com/your-org/your-app/pull/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 a review on the pull request. Its summary says which branch the pull request targets, quotes the star-import check, and for each touched quickstart quotes the surefire summary from ./mvnw verify, with the failsafe summary when the native profile was requested. Findings follow with file and line in the quickstart they belong to, marked blocking or suggestion, and a scope or transaction finding names the annotation to add.
The transcript keeps the Maven download, every command and its output, the target/surefire-reports the build wrote, and the files the agent opened while following a resource into its entity, so when the review says a reactive endpoint blocks, the stack trace or the line is in the record.
Before merging, a reviewer runs ./mvnw verify in the touched quickstart on the branch, with -Dnative if the quickstart supports it, opens each cited line, and decides which suggestions to keep. A test failure, a star import or a pull request against main is blocking by default; a naming suggestion is not.
Run it on every pull request opened
Create an automation in the Project with a github trigger on pull_request.opened and pull_request.synchronize, branch_patterns set to development, and this prompt. The trigger adds the pull request after the prompt, so each pull request and each push to it gets its own sandbox, its own Maven repository and its own review, and a read_only automation can comment but not push.
The review is the result on the pull request; the run is listed in the Project. max_runs_per_hour, 1 to 30, bounds a release week when many quickstarts are bumped at once; a fire past the cap is skipped as rate_limited and that pull request is reviewed on its next push. The repository's own CI still builds Quarkus main and runs the native matrix, which the sandbox does not replace.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
A quickstart change is small and its proof is expensive: a Maven wrapper per module, a platform BOM download, surefire under the JBoss log manager, a Dev Services container for anything with a database, and a native profile that only the integration test exercises. Reviewers who cannot spare that read the diff and hope. On Rush the agent runs ./mvnw verify in its own sandbox for exactly the quickstarts the diff touches, keeps the reports, and posts findings that cite them, so a blocking call in a reactive endpoint is shown rather than suspected.
One sandbox per pull request means a change to getting-started and a change to hibernate-orm-panache-quickstart are built and reviewed at the same time, with separate Maven state, and nothing is pushed to the contributor's branch. The reviewer gets findings with the surefire output attached and the contributor gets the same result CI would give, with the branch policy from CONTRIBUTING.md checked up front.
Frequently asked questions
Does it build the whole repository?
No. It runs ./mvnw verify inside each quickstart the diff touches, using that quickstart's own wrapper and pom.xml. The root incremental profile with gitflow-incremental-builder is available for a root build of only the changed modules, and the agent uses it when the diff touches the root pom.xml.
What about tests that need a database or a broker?
Quarkus Dev Services starts the service in a container when no %test datasource or connection is configured, as in hibernate-orm-panache-quickstart. The agent checks whether the sandbox can start containers first; when it cannot, the review lists the tests it could not run instead of counting them as passed.
Does it run the native build?
Only when asked in the prompt, since -Dnative needs GraalVM or Mandrel, which the quickstart READMEs list as a requirement, and the CI runs native builds on a separate daily matrix. The review notes whether a touched quickstart has an *IT class so a maintainer knows the native leg exists.
Which Java version does it use?
The pull request workflow runs JDK 21 while each pom.xml targets source and target 17, so the agent builds on 21 and flags a diff that uses a language feature past 17 or bumps maven.compiler.source in one quickstart only.