What the agent does
The agent starts from go.mod. In gothinkster/golang-gin-realworld-example-app the module declares Go 1.21 and depends on gin v1.10.0 for HTTP, gorm v1.25.12 with its SQLite driver for storage, golang-jwt/v5 for tokens and stretchr/testify for assertions. Tests are unit tests colocated per package: articles/unit_test.go, users/unit_test.go and common/unit_test.go sit beside the code they cover.
It checks out the pull request branch and runs go test ./.... Each package compiles against its neighbours, so a change to articles that breaks users fails the build of both, and the output names the package and the failing assertion. Because the storage driver is the SQLite one, the suite needs no external service.
It reads the diff in the users and articles packages with the handlers and stores they touch. A handler that binds JSON but never checks the validator error before using the struct, a store method that looks a record up by the wrong slug column, a route registered without the JWT middleware its siblings carry: each candidate finding is run against the unit tests to see whether one already pins the behaviour.
One GitHub review is posted per run. The summary quotes the go test ./... result, separates blocking issues from suggestions, and every finding cites file and line in the package it belongs to. The prompt forbids pushing commits, and the run pushes none.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Review this pull request. Check it out, install dependencies with Go modules, run `go test ./...`, and read the diff with the surrounding code in the users and articles packages. Post one GitHub review that cites file and line for every finding, separates blocking issues from suggestions, and includes the test result. 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. The summary quotes the go test ./... result, lists the findings with file and line in users or articles, and marks which block merge and which are suggestions. Inline comments sit on the cited lines.
The session's trajectory keeps the module resolution, the test run and the files the agent opened while tracing each handler into its store. When a finding claims a lookup uses the wrong column, the trajectory shows the query it read.
Before merging, a reviewer reproduces the blocking findings with go test ./... on the branch and opens each cited line. Suggestions can be dismissed without holding the merge.
Run it on every pull request opened
Create an automation with a GitHub trigger on pull_request.opened and pull_request.synchronize, limited to the branch the service merges to, and this prompt. Every pull request then gets its own run in its own sandbox, and the review lands with the suite already executed.
Set a webhook URL on the API key and Rush POSTs run.completed when a run's turn finishes, with the session URL. Your server can post the review link to the channel that watches the service's pull requests. A key admits at most max_concurrent runs, 4 by default, and answers 429 beyond it, so a burst of small pull requests should queue its starts.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
A Go review on a laptop is quick to start but still costs a checkout, a context switch and the go test ./... wait before the first comment. On Rush the agent does that in its own sandbox and keeps every command and its output in the trajectory, so the review is backed by an executed suite and the record shows which packages ran and what they returned.
One sandbox per pull request keeps reviews parallel when the service takes changes from several contributors at once, each with its own run of the full ./... tree. The author keeps their checkout, the reviewer keeps their focus, and the result cites file and line with the test result quoted.
Frequently asked questions
Which Go version does it build with?
The one go.mod declares, 1.21 in this repository. The agent reads the module file first and the toolchain line governs, the same way CI pins it.
Will it run the race detector?
Ask for go test -race ./... in the prompt and the review quotes any race it finds, with the goroutines the detector names. Without it, the run uses the plain go test ./... the prompt names.
Does it need a database for the tests?
Not for this repository: the storage driver in go.mod is the gorm SQLite driver, so the unit tests run entirely in the sandbox. A service whose tests expect Postgres or MySQL gets the connection string from the prompt or a Project secret.
What if go vet or staticcheck would catch it faster?
Name the tool in the prompt and the agent runs it and quotes its output alongside the tests. The review still cites file and line, whatever surfaced the finding.