# Review Pull Requests Automatically in a Go Service

Yes. An agent checks out the pull request, runs go test ./... in its own sandbox, and posts one review citing file and line for each finding.

[Run this on Rush](https://cloud.getrush.ai/run/review-pull-requests/go/), in a Project that has your repository.

## 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`

```json
{
  "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"
    }
  ]
}
```

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.
2. **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.
3. **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.

## 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.