# Review Pull Requests on a FastAPI API Yes. An agent checks out the pull request, runs uv run pytest and the lint script 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/fastapi/), in a Project that has your repository. ## 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` ```json { "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" } ] } ``` 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 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. ## 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.