What the agent does
The agent checks out the pull request's branch in its own sandbox and reads how the repository tests itself before it reads the diff. In dani-garcia/vaultwarden, .github/workflows/build.yml runs on every push that touches src/**, migrations/**, Cargo.*, build.rs, rust-toolchain.toml, rustfmt.toml, diesel.toml or macros/**, with a two-row matrix: the rust-toolchain channel, 1.99.0 from rust-toolchain.toml, and msrv, 1.97.1 from rust-version in Cargo.toml. It installs libmariadb-dev-compat, libpq-dev, libssl-dev and pkg-config, sets RUSTFLAGS=-Dwarnings, and runs cargo test --profile ci six times over feature sets: all five features, without s3, without enable_mimalloc, then sqlite, mysql and postgresql alone. Clippy runs once with sqlite,mysql,postgresql,enable_mimalloc,s3, and cargo fmt --all -- --check on the toolchain row only. The agent runs the toolchain row: cargo test --profile ci --features sqlite first for speed, then clippy with all features and the fmt check, and quotes each result in the review.
Then it reads the diff with the files the change depends on. A handler in src/api/core/ is an async fn with request guards from src/auth.rs and a DbConn; the agent checks which guard the new route takes, since Headers admits any logged-in user while OrgHeaders, AdminHeaders, ManagerHeaders and OwnerHeaders check membership and role, and a route that reads organization data behind Headers alone is a finding. Queries go through conn.run(move |conn| ...) or db_run!, which compiles a body per backend, so a Diesel expression that uses a SQLite-only function or a type the Postgres schema does not have is caught by the three-backend clippy run and quoted with the compiler message. A new table or column must appear in all four migrations/ directories (sqlite, mysql, postgresql, cockroachdb) and in src/db/schema.rs, and the review lists any backend the change forgot.
The error contract gets its own pass. src/error.rs turns every err! into a 400 with an ApiErrorResponse body and logs the message at error level, so the review flags an unwrap() or expect() on data that comes from the client or the database, a ? on a type with no From impl, and a message that leaks an internal path. [workspace.lints.rust] forbids unsafe_code and denies warnings and the edition compatibility groups; [workspace.lints.clippy] warns on pedantic, style, perf and suspicious, and CI's -Dwarnings turns those into failures, so a needless_pass_by_value in a new helper is a blocking finding with the clippy line attached. rustfmt.toml sets max_width = 120 and use_small_heuristics = "Off", which the fmt check enforces.
The review is one GitHub review with blocking findings separated from suggestions, each citing file and line, and the three command results at the top. The agent pushes no commits and opens no second pull request. A change under playwright/ or docker/ is noted as outside the Rust checks, since the Playwright suite needs Docker Compose and the Dockerfile has its own hadolint.yml workflow.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Review the open pull request on this Rocket server. Check it out and read .github/workflows/build.yml, rust-toolchain.toml and Cargo.toml first; in a server shaped like dani-garcia/vaultwarden, build with the pinned toolchain and RUSTFLAGS=-Dwarnings, run cargo test --profile ci --features sqlite, cargo clippy --profile ci --features sqlite,mysql,postgresql,enable_mimalloc,s3 and cargo fmt --all -- --check, and quote each result. Read the diff with the files it depends on: the request guards in src/auth.rs that each changed route takes, the Diesel queries run through conn.run or db_run! and whether they compile for every backend, the migrations/ directories a schema change must all update, and every unwrap, expect or err! on data from the client or the database. Post one GitHub review that cites file and line for every finding, separates blocking issues from suggestions, and includes the command results. 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 full command log on the session. The review opens with the results of cargo test --profile ci --features sqlite, the five-feature clippy run and the fmt check, then lists blocking findings and suggestions, each with a file and line: a guard that admits too much, a query that only compiles for SQLite, a missing MySQL migration, an unwrap on a client value. A compile or clippy failure is quoted as the result rather than worked around.
Before acting on it, a maintainer checks the guard findings first, since they decide who can reach data, then the backend findings, and treats the style items as optional. The session's result holds the review text, and the transcript shows every command with its output, so a finding can be traced to the line of compiler or clippy output that produced it.
Run it on every pull request opened
Create an automation in the Project with this prompt and a github trigger on pull_request.opened and pull_request.synchronize, with read_only on so its runs can comment but never push. The trigger adds the pull request event after the prompt, and each push to the branch starts a fresh run against the new head. Set max_runs_per_hour to match how often the team pushes, since a server this size compiles for several minutes per run.
To drive it from your own server instead, receive the GitHub webhook, put the pull request URL in resources so the clone is the head commit, and send this body with the delivery id as Idempotency-Key. A webhook URL on the key then receives run.completed with session_url when the review is posted; the first build of a Vaultwarden-sized crate is long, and a key allows at most max_concurrent runs in progress, so start the next review when one finishes.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
A Rocket server that compiles against three databases and denies every warning cannot be reviewed from the diff alone: the question is whether the query compiles for Postgres, whether the guard is the right one, and whether clippy's pedantic group passes under -Dwarnings. On Rush the agent runs those checks in its own sandbox with the pinned toolchain and the system libraries CI installs, and the review quotes what the compiler said instead of guessing.
Every pull request gets the same depth, with the full command record kept on the session, and several open pull requests are several sandboxes at once. The reviewer who merges reads findings with evidence rather than waiting for the CI matrix to say what the agent already found.
Frequently asked questions
cargo test passed with the sqlite feature. Did the other backends run?
The tests ran on SQLite, and clippy compiled the crate with sqlite,mysql,postgresql,enable_mimalloc,s3, which is how CI catches a query that only works on one backend. The review says exactly that, and a maintainer can ask for a follow-up turn that runs cargo test --profile ci --features postgresql with a Postgres started in the sandbox.
Will it flag style under the pedantic group?
Yes, as blocking when CI would fail on it, because -Dwarnings turns the warn level in [workspace.lints.clippy] into an error, and as a suggestion otherwise. Each item carries the clippy line so you can decide.
Does it check the migrations?
It lists the files added under each of migrations/sqlite, migrations/mysql, migrations/postgresql and migrations/cockroachdb and the change to src/db/schema.rs, and names any backend the pull request skipped. It does not run the migrations against MySQL or Postgres unless asked.
Can it review a change to the Playwright tests or the Dockerfile?
It reads them and comments on what it can see, but the Rust commands do not cover them; playwright/ needs Docker Compose with three databases and the Dockerfile is checked by hadolint.yml. The review labels those findings as read-only.