What the agent does
The agent reads the repository's own pins first. In BookStackApp/BookStack it opens composer.json and finds laravel/framework at ^v13.35.0, PHP at ^8.3.0 and phpunit/phpunit at ^12.5.38, with the composer test script running plain phpunit. BookStack adds its own scripts around it: t-reset runs php artisan test --recreate-databases against the mysql_testing database, and refresh-test-database applies migrate:refresh to it.
The tests live under tests/ in per-area directories: Api, Auth, Entity, Activity, Commands, with CreatesApplication.php booting the app for every case. The agent checks out the pull request branch, installs dependencies with Composer, prepares the test database and runs the PHPUnit suite the way the scripts do.
It reads the diff with the framework's conventions in view. An API controller that returns the wrong status for a missing model, validation rules that miss the field the form actually sends, an authorization check on the route but not in the action the route calls, a test that asserts its own setup rather than the change: these are the concrete defects the prompt asks it to comment on, each with file and line.
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 PHPUnit 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, each stating the defect and the behaviour expected instead. The summary quotes the PHPUnit result, so a reviewer sees at a glance whether the suite was green while the comments were written.
The session's trajectory keeps the Composer install, the database preparation, the phpunit run and the controllers, form requests and tests the agent opened while checking each comment against the code around it.
Before merging, a reviewer works through the inline comments in order, runs the suite on the branch if the result is red, and confirms each cited line says what the comment claims. The comments resolve one by one as fixes are pushed.
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 the app 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 PHP 8.3, Composer and a test database.
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 raise the limit when a release branch opens many pull requests at once.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
A Laravel review on a laptop starts with the environment: the right PHP, Composer dependencies, a database for the suite. 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 PHPUnit run already executed and its record attached, not after the reviewer has spent the setup time.
One sandbox per pull request keeps reviews moving when several land together, each with its own database, suite and review. The inline comments cite file and line, the suite result is quoted, and nothing runs on the author's or reviewer's machine.
Frequently asked questions
Which database does the suite use?
BookStack's scripts target a mysql_testing database, and t-reset recreates it before the run. Pass the database credentials in the prompt or as a Project secret and the agent prepares it in the sandbox; the trajectory shows the artisan commands it used.
Can it run one test directory instead of the whole suite?
Yes. Name it in the prompt, for example phpunit tests/Api, and the run limits itself and says so in the review. The default is the full suite, matching the composer test script.
Will it comment on code style?
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 own checks, and the agent does not restyle the diff.
What if the suite fails on a test the pull request did not touch?
The review quotes the failing test separately from the defects it found in the diff, so a pre-existing failure does not read as a verdict on the change. Run the same suite on the base branch to confirm.