What the agent does
The agent checks out the pull request branch in its own cloud sandbox and reads the repository before it changes a line. In a Rails app like codetriage/CodeTriage, the Gemfile pins Rails 8.1.3.1 and .ruby-version pins Ruby 4.0.5, tests are Minitest run by bin/rake test, Sidekiq drives the background jobs in app/jobs, and the app expects PostgreSQL (the CI workflow stands up postgres:16). The agent installs the gems, copies the CI database config, creates and loads the test schema, and runs bin/rake test once on the untouched branch, so a failure it sees later can be told apart from one that was already there.
Then it reads every unresolved review thread on the pull request and treats each on its own. A thread asking for a change (extract a method out of a fat model like app/models/repo.rb, move work into one of the existing jobs such as populate_issues_job, tighten a query) becomes a code change on the same branch. A thread that asks a question rather than requesting a change is answered in a reply, not edited into the code. The agent follows CodeTriage's own style, which the CI runs through standardrb, so its edits pass the linter the project already enforces.
For each change it makes the edit, runs the relevant tests with bin/rake test, and commits with a message that quotes the comment it answers, so the branch gains one focused commit per thread rather than one catch-all commit. It keeps the commits separate so a reviewer can map each back to the thread it resolves.
When the threads are handled it pushes the new commits to the same branch and replies on each thread with the commit that answers it, or with the answer when the thread was a question. It opens no new pull request and starts no second branch; the work lands on the branch under review, which is what a reviewer expects when they leave comments.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Read every unresolved review comment on the open pull request. For each one, make the change it asks for on the same branch, run the tests with bin/rake test, commit with a message that quotes the comment, and reply on the thread with the commit. If a comment is a question rather than a request, answer it on the thread instead of changing code. Follow the repository's existing conventions and keep standardrb passing.",
"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 commits on the pull request already under review: one per thread that asked for a change, each message quoting the comment it answers, pushed to the branch so the existing review keeps its history. Every addressed thread gets a reply linking the commit that resolves it, and every question thread gets a written answer instead of a code change.
The session read returns the pull request URL, the branch and the commits the run pushed; the transcript keeps the gem bundle, the copy of the CI database config, the schema load into PostgreSQL, the baseline bin/rake test, and each later run. A reviewer sees that Minitest ran against a real database and what it reported, and that standardrb stayed green, rather than trusting the fixes on sight.
Before merging, the reviewer confirms each reply matches its change, that commits are one per thread, and that the tests the agent ran reach the models and jobs it edited. Because the branch is the real one, the repository's own CI runs on the pushed commits as it would for any contributor, and the reviewer merges from the pull request once the checks are green.
Run it on every a reviewer requests changes
Run it the moment a review lands. An automation with a GitHub trigger on review and review-comment events starts one run per review, so the small back-and-forth fixes on a Rails pull request are handled while the reviewer's context is fresh rather than waiting for the author to find time.
You can also start it by mentioning the agent in a comment on the pull request, which fires the same request scoped to that pull request. Either way the run reads the unresolved threads as they stand, so a reviewer who adds a comment after the last run still has it picked up on the next one.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
Clearing review comments on a Rails app by hand means fetching the branch, re-reading each thread, editing a model or a job, copying a database config, loading a schema into PostgreSQL, running Minitest and then replying thread by thread. On Rush the agent carries all of that in its own sandbox from a fresh checkout, so your working copy stays put and the Ruby version and database it stands up never land on your machine.
This job is judged by whether a reviewer can trust the result without redoing it. Each change is a single commit that quotes its thread, and the database setup and every bin/rake test run sit in the transcript, so the reviewer sees what each comment produced and that it was checked against a real database. Several pull requests can run at once, one each, up to the key's concurrent-run limit.
Frequently asked questions
Does it push to my branch or open a new one?
It pushes to the branch the pull request is already on, so the existing review and its CI history stay intact. It opens no second pull request and cuts no new branch; a reviewer sees the fixes arrive as fresh commits on the branch they are reviewing.
What happens to a comment that is a question, not a request?
The agent replies to it on the thread rather than editing code. The prompt tells it to tell the two apart, so a reviewer's question gets a written answer and a requested change gets a commit, each posted on the thread it belongs to.
Does it need PostgreSQL to run the tests?
Yes, and it sets it up. CodeTriage's tests run on PostgreSQL; the agent copies the CI database config, creates and loads the test schema in the sandbox, then runs bin/rake test, so the suite runs against a real database rather than a stub.
Can it work on a private repository?
Yes. Install the Rush GitHub App on the repository; the pull request URL in resources is then reachable through that installation. The agent checks out the branch, pushes its commits back, and replies on the threads through the same App.