What the agent does
The agent reads the repository the way a new contributor would. In django/djangoproject.com, the code behind djangoproject.com, it opens requirements/prod.txt and finds django==6.1.1 pinned, the same pin in requirements/tests.txt, psycopg 3.3.4 for Postgres, and pyproject.toml pinning Python to ==3.12.* with a uv.lock. The Makefile's test target runs python -m coverage run --source=. --module manage test, and the site expects a Postgres database rather than SQLite.
It checks out the pull request branch, installs the test requirements, creates the test database and runs the suite with coverage as the Makefile does. The project is split into apps with their own tests: blog/tests.py, checklists/tests/test_models.py, checklists/tests/test_views.py, checklists/tests/test_templatetags.py, djangoproject/tests/test_www_urls.py, so a failure names both the app and the test.
It reads the diff with the surrounding views, models and URLs, and comments only on concrete defects: behaviour that is wrong, error handling that is missing, a test that does not exercise the change it accompanies. A view that swallows a DoesNotExist, a URL pattern change that test_www_urls.py was not updated for, a test that asserts its own fixture instead of the code, are the shapes it looks for.
The review it posts is one GitHub review with inline comments on the cited lines and the suite result quoted in the summary. The prompt forbids pushing commits, and none are pushed.
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 repository. Check out its branch, run the Django test suite, and post a review on the pull request with inline comments on concrete defects only: wrong behaviour, missing error handling, a test that does not test the change. 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. Inline comments sit on the exact lines with the defects, each one stating the wrong behaviour or the missing handling and what should happen instead. The summary quotes the suite result with coverage, so a green suite and a red suite are both visible at the top of the review.
The session's trajectory keeps the run behind it: the dependency install, the test-database setup, the manage test invocation with coverage, and the views and tests the agent read while checking each comment against the code around it.
Before merging, a reviewer works through the inline comments in order, checks out the branch to run the suite if the result is red, and confirms each cited line says what the comment claims. Because the comments are on lines, they resolve one by one as fixes land.
Run it on every pull request opened
Create an automation with a GitHub trigger on pull_request.opened and pull_request.synchronize, pointed at the branch your team merges to, and this prompt. Every pull request then gets its own run in its own sandbox, and the inline review appears without a developer setting up Python 3.12 and a database first.
Set a webhook URL on the API key and Rush POSTs run.completed when the run's turn finishes, with the session URL. Your server can post the review link to the pull request or the team channel. A key admits at most max_concurrent runs, 4 by default, and answers 429 beyond it, so a repository with a busy Friday should queue or raise the limit.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
A Django review on a laptop starts with environment work: the pinned Python, the test requirements, a Postgres instance, the test database. On Rush the agent does that in its own sandbox and keeps every command and its output in the trajectory, so the review arrives with the suite already run and the record of the run attached, instead of after a developer has spent the setup time.
Running one sandbox per pull request also keeps reviews moving when several land together: each gets its own database, its own suite and its own review, none waiting on a colleague's laptop. The comments cite file and line, the suite result is quoted, and nothing runs on the author's or reviewer's machine.
Frequently asked questions
Can it run just one app instead of the whole site?
Yes. Name the app in the prompt (python manage.py test blog) or use the Makefile's APP_LIST variable, and the run limits the suite and says so in the review. The default is the full project, matching the Makefile's test target with coverage.
Does it need our production settings or data?
No. The suite runs against a test database the agent creates in the sandbox, using the pinned test requirements and the environment variables the settings module expects. Production settings and data are never part of the run.
Will it comment on Django style or formatting?
The prompt limits it to concrete defects: wrong behaviour, missing error handling, tests that do not test the change. Style belongs to the project's lint configuration, and the agent does not restyle the diff.
What if a test fails that the pull request did not touch?
The review separates pre-existing failures from defects introduced by the diff, quoting both, so a red suite on an unrelated test does not read as a verdict on the change. A reviewer can confirm by running the same suite on the base branch.