Act on a review

A review is most useful when the author deals with it before a teammate looks at the merge request. This guide suggests a simple routine for authors and reviewers.

For the author

1. Start with the risk

Risk	Suggested approach
Low	Skim the findings, fix anything quick, and ask for review.
Medium	Read every finding. Fix or reply to each one before asking for review.
High	Treat it as a stop sign. Read the summary and every blocker or high finding before doing anything else.

2. Work through findings by severity

Go from most to least serious:

1. Blocker: don’t merge until it’s fixed or you’ve explained why it isn’t a problem.
2. High: a likely bug or security issue. Fix it, or explain in the MR.
3. Medium: worth fixing now if it’s cheap; otherwise create a follow-up issue.
4. Low and Nit: optional improvements and style. Fix what you agree with.

3. Use confidence to decide how hard to look

Each finding has a confidence of high, medium or low.

• High confidence: the model is fairly sure. Check the line and fix it.
• Low confidence: the model is unsure, often because the problem depends on code outside the diff. Spend a minute confirming before you change anything.

A high severity, low confidence finding deserves a careful look: it’s unlikely but expensive if real.

4. Answer the questions

Questions for the author usually point at missing context: why a change was made, how an edge case should behave, or whether something was deliberate. Answer them in the merge request description or a comment. Human reviewers will often have the same questions.

5. Push and get a fresh review

Each push triggers a new review, which replaces the old comment. Findings you’ve fixed should disappear and the risk should drop.

When you disagree with a finding

The model works from the diff, so it sometimes lacks context or gets things wrong. When a finding is wrong:

1. Reply on the merge request explaining why, for example “This input is validated by the middleware in auth.ts.” That helps human reviewers and leaves a record.
2. Don’t change correct code just to satisfy the bot.
3. If the same false finding keeps coming up, adding a short comment in the code often helps, because the model reads it next time.

For reviewers

• Read the summary first. It’s often the quickest way to understand a change.
• Check what the author did with blockers and high findings before reading the code in detail.
• Focus your time on what the model can’t judge: whether the change is the right one, design, naming, product behaviour and how it fits the rest of the system.
• Use the risk to prioritise. In the portal, filter Reviews by Flagged to see everything that wasn’t approved. See review history.

Suggested team agreement

Some teams write down a short agreement. For example:

• Authors deal with every blocker and high finding before requesting review.
• Medium findings are fixed, replied to, or turned into follow-up issues.
• Reviewers don’t repeat a finding Pullwise already made. They check it was handled.
• High-risk merge requests need two human approvals.

Next

Track review history and the dashboard.