How to Write Review Feedback a Coding Agent Can Turn Into a Verified Fix

A developer has published a guide for writing code review feedback that coding agents can turn into verified fixes, using the public PR #60 discussion in real-browser-mcp as a worked example. The approach asks reviewers to state the problematic behavior, the conditions that trigger it, and the outcome to preserve, then require a test that fails against the old code and passes against the fix. It also distinguishes merge-blocking bugs from deferrable suggestions and notes that GitHub's "request changes" state only blocks a merge when branch protection rules say so.

Short answer: describe the problematic behavior, the conditions where it appears, and the outcome you want preserved. Ask for a focused fix and a test that fails against the old behavior. Separate a merge-blocking problem from an improvement suggestion that can wait. A comment like "this needs cleaning up" leaves the real work to whoever received it. To turn a comment into a task, write what can be done in the system and what happens as a result. The public discussion on PR 60 in real-browser-mcp shows concrete problems: two concurrent actions on the same tab could create two groups, and two debugger connections could leave more than one tab attached when only one was tracked. The PR reply also describes what needs testing. These are sources for a scenario, not proof that every possible browser environment was covered. The following phrasing is a proposed template: When two requests reach the same resource before the first one completes, the system must preserve the agreed outcome. Show a test that reproduces the collision against the old version, fix the behavior, and show the test passing against the new version. State what was not tested. "The agreed outcome" has to be replaced with a real requirement: one group, one connection, or a clear error. Each of those is a different decision. If there is no agreement, open a discussion before asking the agent to choose. A review can address a bug, a design question, or code cleanliness. Mark which kind of comment you wrote. A variable-name suggestion is not equivalent to a permissions fix, even if both appear in the same thread. GitHub's documentation describes three review states: comment, approve, and request changes. Whether "request changes" blocks a merge depends on the branch protection rules. Writing the word "blocker" in a comment is not a technical definition of a repository rule. When a change contains two separate mechanisms, you can ask for a split. In the public example, tab-group management and debugger handling were separated into two PRs. The split lets you verify intent and evidence for each part without tying them to one bundle. Splitting is a working tool, not a goal in itself. If two parts must land together to keep behavior correct, document the dependency and the merge order. An agent can prepare the branches, but the decision about the shared contract stays with the change owner. Before approving, read the new diff and the added test. Make sure the test touches the behavior raised in the discussion, not only the way the current code happens to be written. Ask for a run result, a version, and a command. A planned-test list in the PR body is not a run result. If the agent summarizes "all comments addressed," send it back to the original list. Every comment needs a fix, an explanation of why it is not required, or a decision to defer it. A thread that scrolled off the screen is not evidence the problem was solved. A good fix connects the comment, the requirement, and the evidence. That way, whoever reads the PR later understands why the change went in and what it is supposed to preserve. The goal of review is to improve behavior and provide a way to verify it, without turning the person receiving the feedback into a guesser. In my post about contributing to real-browser-mcp, I described a contributor who came back after review with two separate PRs and fixes for the cases found in testing. This guide proposes a working approach that can be applied to another contribution, without assuming every change has already been tested. Describe the problematic behavior, the conditions where it appears, and the outcome you want preserved. Ask for a focused fix and a test that fails against the old behavior. Separate a merge-blocking problem from an improvement suggestion that can be deferred. GitHub supports comment, approve, and request changes as review states. The actual blocking depends on the branch rules, not just the wording of the comment. It can prepare fixes and evidence within agreed boundaries. A design question or a contract change requires an explicit decision. When there are separate mechanisms that can be verified independently. When there is a dependency, document it along with the order the changes should land. Ofer Shapira - AI builder and lead in development teams, writing about agents, decisions, and workflows you can verify.