What the agent does
The agent checks out the pull request and reads Cargo.toml before it builds. In a service shaped like launchbadge/realworld-axum-sqlx the package is realworld-axum-sqlx 0.1.0, edition 2021, publish false. There is no rust-toolchain file. Dependencies pin axum 0.3.4 with the tower-log feature, tokio 1.14.0 with macros and rt-multi-thread, sqlx 0.5 with runtime-tokio-native-tls, postgres, uuid and time, clap 3.0.0-beta.5, argon2 0.3.1, and jwt 0.15.0 with hmac 0.11.0. Migrations live in migrations/ as 1_setup.sql, 2_user.sql, 3_follow.sql and 4_article.sql. The README's database path is sqlx-cli with the postgres feature and sqlx db setup once DATABASE_URL is in .env.
Article handlers are the code the review reads with the diff. src/http/articles/mod.rs is 614 lines and builds the router: POST and GET /api/articles, GET /api/articles/feed, GET PUT DELETE /api/articles/:slug, POST and DELETE favorite, GET /api/tags, then comments::router(). CreateArticle deserializes title, description, body and tag_list with rename_all camelCase. UpdateArticle leaves tag_list out. ArticleFromQuery flattens the author columns and into_article builds the Profile. slugify lowercases ASCII and strips quotes. The only unit test in the crate is test_slugify at the bottom of that file. It asserts three titles, including a title that ends in the digits 1, 2, 3. src/http/articles/listing.rs is the list and feed queries. src/http/articles/comments.rs is the comment routes. Handlers that hit Postgres are not unit-tested here. The file's own comment says the RealWorld API suite lives outside this repository.
cargo test is the command, and on this crate it compiles the library and runs test_slugify. It does not apply migrations and it does not call the HTTP routes. The agent runs it anyway and puts the output in the review, including a compile error if the diff breaks slugify or a handler signature. It does not install sqlx-cli or invent DATABASE_URL to turn the unit test into an integration run. If the diff adds a test that opens a pool, the failure to connect is part of the quoted result. The agent does not push a fix for that failure.
The review cites file and line. Blocking findings are a handler change that drops a field the RealWorld shape requires, a slugify change that fails test_slugify, or a query in listing.rs that forgets the caller in AuthUser versus MaybeAuthUser. Suggestions are a new SQL branch with no test, or a comment that the outside integration suite is still the only cover for create_article. Comments in mod.rs are long and opinionated. The review does not treat those comments as findings unless the diff makes the code contradict them. One review, no extra commits.
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 the Axum and SQLx RealWorld API. Check it out and run cargo test. Read the diff with src/http/articles/mod.rs, src/http/articles/listing.rs and src/http/articles/comments.rs. The in-repo test is test_slugify. Do not install sqlx-cli unless a test in the diff requires a database, and if cargo test cannot reach Postgres, quote that failure. Post one GitHub review that cites file and line for every finding, separates blocking issues from suggestions, and includes the cargo test result. Do not push commits.",
"resources": [
{
"url": "https://github.com/your-org/your-app/pull/1"
}
]
}- 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 and the cargo test log on the session. The session read names the repository and the pull request. The review states how many tests the crate compiled, which on the current tree is the slugify test, and then lists findings against the article routes. A compile failure is the test result and is labeled as such. The agent does not open a second pull request or push a green fix onto the author's branch.
A reviewer checks that a passing cargo test is not described as a passing API suite. test_slugify does not insert a row into the article table from 4_article.sql, and listing.rs is unchecked by that test. The transcript's tool_result for cargo test is the evidence. GET /o/{org}/sessions/{id} has the final answer in result when the turn has finished. A follow-up can ask the same sandbox to cargo test one function again after you have read the review.
Run it on every pull request opened
Your server receives pull_request.opened and POSTs this session. resources is the pull request URL, so the clone is the head commit, through the GitHub App installed on the repository. Idempotency-Key should be the delivery id. Cargo's target directory stays in that sandbox, which parks with its disk when the turn ends, so a synchronize review that reuses the session would need a follow-up rather than a new clone. A new session is the right call for a new pull request.
run.completed on the key's webhook is the signal the review was posted. The payload includes execution_id, status and session_url. Signature headers follow Standard Webhooks. Rust compiles are long, and starting past max_concurrent answers 429, so a repository with a stack of opened pull requests should start the next session when one reaches a finished status.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
cargo test on this crate still compiles axum 0.3.4, sqlx 0.5 and tokio, which is a large fetch to do on a laptop for every pull request, and the target directory fights with whatever else you are building. The sandbox compiles there and keeps the log. You do not need the Rust toolchain locally. The parked sandbox holds the build for a follow-up, for up to 7 idle days, and costs nothing while parked.
The review is specific because the test surface is specific. Quoting cargo test next to test_slugify stops a reader from thinking the article handlers were executed. Findings cite slugify, the router in mod.rs, or a query in listing.rs, with the line. Several services can be reviewed at once, each sandbox with its own Cargo cache, and the pull request receives one review a person can answer.
Frequently asked questions
cargo test passed. Did the article routes run?
Not on this crate. The only #[test] is test_slugify in src/http/articles/mod.rs, and it compares strings. Handlers that need Postgres are not called. The review says that. The README points at an external RealWorld API suite, which this request does not run.
Will it run sqlx migrate or start Postgres?
Only if you add that to the input. The default request is cargo test, which does not read migrations/. The agent does not create a DATABASE_URL the repository does not commit. A diff that adds a database test will show the connection error in the quoted output.
There is no rust-toolchain file. Which toolchain does it use?
The sandbox's default Rust toolchain, because the repository does not pin one. Edition in Cargo.toml is 2021. The review should say the toolchain it actually ran, from the cargo test preamble, so you can compare it with what your CI image uses.
Will the review rewrite the long comments in mod.rs?
It does not push, so those comments stay. They are context for slugify and for why handlers are not unit-tested. A finding is about the code the diff changes. A comment that disagrees with a new branch is worth citing. A style note on the comment itself is a suggestion, not a blocking line.
Can I review a change outside articles?
Yes. resources checks out the whole pull request. Name src/http/users.rs or src/http/profiles.rs in the input when that is the diff, and keep cargo test so the slugify test still runs as the crate's suite. One session still takes one repository.