# Address Review Comments on a Laravel Pull Request

Yes. An agent reads the review comments on your Laravel pull request, fixes each one on the same branch, runs the tests, and replies on the thread.

[Run this on Rush](https://cloud.getrush.ai/run/answer-review-comments/laravel/), in a Project that has your repository.

## 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 Laravel app like koel/koel, `composer.json` requires PHP 8.3 and Laravel 13, `phpunit.xml.dist` runs three suites (feature, unit, integration) against SQLite in memory, and the `test` script is `@php artisan test --parallel`. `package.json` pins pnpm and runs the Vue front-end tests with `pnpm test`. The agent installs PHP and JavaScript dependencies and runs the suite 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 one on its own. A thread asking for a change (rename a method to read like `isRegisteredForDiscounts`, extract a query into a builder, add a policy check on a controller in `app/Http/Controllers/API`) 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 koel's own conventions, which its `AGENTS.md` ties to the Laravel Boost guidelines: match sibling files, reuse existing components, and do not add dependencies.

For each change it makes the edit, runs the relevant part of the suite with `artisan 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`

```json
{
  "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 artisan 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 add no dependencies.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app/pull/1"
    }
  ]
}
```

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 new commits on the pull request already under review, not a new one: one commit per thread that asked for a change, each message quoting the comment it answers, pushed to the same branch so the existing review keeps its history. Each addressed thread gets a reply linking the commit that resolves it, and each question thread gets an answer.

The session read returns the pull request URL, the branch, and the commits the run pushed, and the session transcript keeps every command: the install, the baseline test run, and the test run after each change. A reviewer can see that the suite was run and what it reported, rather than trusting that the fixes are safe.

Before merging, the reviewer checks that each reply matches the change, that the commits are scoped one per thread, and that the tests the agent ran actually cover the code it touched. Because the branch is the real one, GitHub's checks run on the pushed commits as they would for any contributor, and the reviewer merges from the pull request as usual once they are green.

## Run it on every a review left on a pull request

Run it when a review comes in. An automation with a GitHub trigger on review and review-comment events starts one run per review, so the small round-trip fixes are handled as soon as the comments land instead of waiting for the author to pick them up.

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 current unresolved threads, so it always works from the latest state of the review.

## Why run it on Rush?

Addressing review comments by hand means pulling the branch, re-reading each thread, making small edits, running the suite and replying one thread at a time. Run on Rush, the agent does this in its own sandbox against a fresh checkout of the branch, so your working copy is untouched and the PHP and Node toolchains it installs never touch your machine.

The point of this job is a reviewer who can trust the result. Because every change is a separate commit that quotes its thread and the test runs are in the transcript, the reviewer sees exactly what each comment produced and whether it was verified. Several pull requests can be handled at once, one run 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 same branch the pull request is on, which is what a reviewer expects when they leave comments. It opens no new pull request and starts no second branch; the commits land on the branch under review.

### What happens to a comment that is a question, not a request?

The agent answers it on the thread instead of changing code. The prompt tells it to distinguish the two, so a question gets a reply and a request for a change gets a commit, each on the thread it belongs to.

### Will it run the tests before pushing?

Yes. It runs the suite once on the untouched branch to establish a baseline and again after its changes, using the repository's own artisan test command, and the runs are in the session transcript so you can see what passed.

### 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.