Review a code teammate's proposed change

A code change needs evidence that it solves the stated problem without unrelated edits. Review the diff and behavior before accepting the tool’s completion message.

Work through these checks

1. Scope

compare changed files with the brief. Record the evidence or the unresolved question before moving on.

2. Behavior

reproduce the relevant before-and-after case. Record the evidence or the unresolved question before moving on.

3. Checks

inspect actual test output. Record the evidence or the unresolved question before moving on.

4. Inputs

review boundary and failure behavior. Record the evidence or the unresolved question before moving on.

5. Release

separate code acceptance from deployment. Record the evidence or the unresolved question before moving on.

Put the checklist to work

For a parser fix, include a malformed input and a valid boundary input rather than testing only the happy path.

Keep the checklist beside the task brief and the actual output. Mark a check complete only after inspecting the relevant file, setting or event. If a required check cannot run in the current environment, describe that gap and choose an appropriate next review rather than substituting a confident summary.

A boundary to remember

A generated test report is not proof that tests ran; inspect the actual execution evidence.

For the corresponding controls and troubleshooting steps, read the desktop help guide. These checks are a practical review aid; adapt them to the specific source material and intended use of your deliverable.