What the agent does
The agent reads the backend project before running anything. In fastapi/full-stack-fastapi-template the backend is its own Python package: backend/pyproject.toml names it app, pins requires-python to >=3.14, and depends on fastapi[standard] >=0.141.1 and sqlmodel >=0.0.46. Dependencies run through uv, tests live in backend/tests, and the entry points are the scripts in backend/scripts: test.sh runs FASTAPI_ENV=development coverage run -m pytest tests/ followed by a coverage report, and lint.sh runs mypy app, ty check app, ruff check app and ruff format app --check.
It checks out the pull request branch, syncs the environment the lockfile describes with uv sync, then runs uv run pytest and the lint script. uv run puts the project's own environment on the command, so the pytest, mypy and ruff versions are the repository's, not whatever happened to be installed. The tests drive the app through TestClient with a session-scoped db fixture in tests/conftest.py that initializes the database once and cleans the tables afterwards.
It reads the diff with the backend's structure in view: route modules under app/api/routes (items, login, users), shared dependencies in app/api/deps.py that yield the SQLModel session, response models declared on the routes, and Alembic migrations at alembic/. A route that returns a payload its response model does not admit, a dependency that commits or closes the session around the endpoint's back, a session used across an await without a fresh one, are the shapes it checks with the prompt's focus on dependency injection, response models and session handling.
One GitHub review is posted per run with the pytest and lint output quoted, findings citing file and line, and blocking issues separated from suggestions. Nothing is committed and nothing is 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 it out, run uv run pytest and the backend lint script, and post one review that cites file and line for every finding, paying particular attention to dependency injection, response models and SQLModel session handling. 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 pytest result and the lint script's four checks, then lists the findings with file and line, each marked blocking or suggestion. A type error mypy flags and a test failure are reported as separate facts, not blended into one verdict.
The session's trajectory keeps the uv sync, the uv run pytest and lint invocations with their output, and the route, dependency and model files the agent read while checking each finding. A reviewer who wants to contest a session-handling claim can see the exact code the agent based it on.
Before merging, a reviewer reproduces the blocking findings on the branch with uv run pytest and the lint script, and opens the cited lines. 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 backend merges to, and this prompt. Every pull request then gets its own run in its own sandbox, and the review arrives with the suite and the type check already run.
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 forward the review link to the pull request's channel. A key admits at most max_concurrent runs, 4 by default, and answers 429 beyond it, so a monorepo that opens backend and frontend pull requests together should raise the limit.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
A FastAPI review on a laptop means standing in the backend directory, syncing the uv environment and waiting through pytest, mypy, ty and ruff before writing a word. On Rush the agent does that in its own sandbox, and the trajectory keeps every invocation and its output next to the review, so a claim about a response model is backed by the executed suite and type checks rather than by reading the diff.
One run per pull request keeps a busy API moving: each pull request gets its own environment, its own suite and its own review, in parallel, and the reviewer keeps their checkout and their afternoon. The result is checkable, file and line for every finding, with the test and lint output quoted at the top.
Frequently asked questions
Does it run the type checks or only the tests?
Both. The prompt names the lint script, and lint.sh runs mypy and ty check over app as well as the ruff checks. The review quotes the output of each, so a change that passes pytest but fails mypy is still flagged.
Does it need a Postgres database for the tests?
The template's tests drive the app through TestClient with the database the settings configure, and test.sh sets FASTAPI_ENV=development for the run. If your fork points the tests at Postgres, name the connection details in the prompt or a Project secret and the agent sets it up in the sandbox.
Our backend has a different layout. Does the prompt still apply?
The prompt names jobs (uv run pytest, the lint script) rather than paths, so it adapts to where the scripts live. It still reads pyproject.toml and the scripts first, and the review describes what it actually ran.
Does the review cover the React frontend?
This request reviews the backend: pytest and the lint script run in backend/. The template keeps the frontend in its own directory with its own toolchain; name it in the prompt if the pull request touches it and the agent reports on both.