How to review a pull request when you didn't write the code
You asked for a change, and a pull request came back. Reviewing it is the moment the change is yours to accept, adjust or decline, and it takes about two minutes. The six steps below read one in order, without opening the code.
Overview
The review is your control.
An agent's change waits in a pull request for your decision, and working through issues, branches and pull requests is what lets you steer the software one reviewed step at a time. Public pull request 1613 below shows the exchange at its simplest: a one-sentence comment in, a commit out.
Reading a pull request well means asking six questions, each answered by a part of the page. The examples below come from public pull requests on ProPR's own repository.
- What was asked, and does the summary say it was done?
- What does the change look like?
- What does the AI review say, and what is the score?
- Is there anything you want changed?
- Are the checks green?
- Is it ready to merge?
1. Read the summary and the linked issue first.
ProPR starts every pull request description with what the agent did, a Closes #… line that links the issue it came from, and the execution details: which model worked, how long it took and what it cost. Open the issue in a second tab and compare the two. The question is plain: did the agent do what the issue asked, all of it and nothing else?
When the summary mentions something the issue never asked for, that is your first comment.
The description: summary, linked issue, model and cost
2. Look at the change before the code.
When the change touches a screen and the repository has visual previews switched on, the agent captures the changed screen and ProPR puts the capture in the pull request description. Look at it the way you would look at a finished page: does it show what you asked for? A change with nothing to see, such as a faster database query, gets no capture.
Some projects also publish a temporary copy of the app for every pull request. When yours does, its link sits in the pull request conversation or the checks list, and clicking through is the best review there is.
The Files changed tab shows the code itself. You never have to open it to make a good decision.
The capture lands in the description
3. Read the AI review and its score.
Comment /review on the pull request and a second model reads the change against the issue and the conversation, then posts a review in four fixed parts. It never edits the code.
- Overall evaluation. A short summary of what the change does. Read this one even if you skip the rest.
- Merge blockers. Problems the change introduced, numbered
F1,F2and so on, each with the required behaviour, the evidence and the minimum fix. One open blocker means wait. - Suggestions. Optional improvements, numbered
S1,S2and so on. Take them or leave them. - Score: N/10. The reviewer's overall confidence. A 6 with a blocker says fix first; a 9 with no blockers says the reviewer found nothing in the way.
Ask a second model for an opinion
Models disagree, and a second opinion is one comment away. Name the models on the /review line and each one posts its own independent review:
/review claude-fable51 codex-astraLines below the command steer the review. Ask it to focus on the part you care about, such as the checkout flow or error handling. A public case where the second model blocked the merge.
A merge blocker: the rule, the evidence, the minimum fix
4. Ask for a change in a plain comment.
Write what you want as an ordinary comment on the pull request, the way you would message a colleague. No command, no special words. ProPR picks it up, makes the change on the same branch, and replies with the commit it made and what it verified. Paste a screenshot of the problem and the agent sees it. A comment on a specific line carries that line with it.
To apply what the AI review found, copy the /fix line at the end of the review, delete the numbers you disagree with, and post it. /fix F1 resolves only that blocker.
Every follow-up commit comes with an undo link in its reply, which reverts that follow-up and nothing else.
The request
The reply
5. Read the checks.
Checks are the project's automated tests and builds, run on every commit. The pull request shows them as a list near the bottom with a green tick or a red cross, and the Checks tab holds the details. People call this CI.
Green means the automated tests agree the change is safe. Red means something failed, and the failing check's name says roughly what. With automatic CI follow-up switched on for the repository, ProPR reads the failure, posts the evidence as a comment, and comes back with a fix commit on the same pull request. Checks run again on the fix. Without it, paste the failure into a comment and the same thing happens.
A yellow dot means the checks are still running. Wait for them.
A red check becomes a fix on the same pull request
6. Merge when all four are true.
- The summary matches the issue, and you have seen the change or its capture.
- The latest AI review lists no open merge blockers.
- Every change you asked for has a reply with a commit.
- The checks are green.
Then press Merge pull request in GitHub. The change becomes part of the product. For work you have come to trust, switch on auto-merge for a plan or task and the pull request merges on its own once its checks pass; paths you mark as protected always wait for a person. The pull request stays in the history either way, with a Revert button that opens the undo as a new pull request; when later changes built on it, the revert may need a follow-up. Backing a change out.
Merged
The whole story, in one place.
Every pull request in ProPR keeps the list of runs that shaped it: the implementation, each review and its score, each fix, and each follow-up from a comment. Open the pull request in ProPR and the sequence reads like a diary of the change. Try it on the live demo, or start on ProPR Hosted and review your own first pull request today.
