Use case
How do you approach this?
AI-Generated Pull Request Review Checklist
Published · Updated
Published by Unrust. Scoring and editorial method
Quick answer
Before approving an AI-generated pull request, record the requested behavior, the affected boundary, a reproduction that fails on the proposed code, and the result after the fix. This workflow turns a fluent explanation into checkable evidence. Use the linked tutorial when you want a line-by-line bug example.
Start the review with a concrete contract
Example ticket: a list-preview helper must return no entries when limit is zero, default to three only when the limit is omitted or null, and reject negative or fractional limits. The proposed change uses limit || 3. Write the zero-limit expectation before debating the implementation.
Attach evidence to the pull request
Run the same assertions against the proposal and repair. For the example ticket, a zero-limit assertion fails on the proposal. After the fix, zero, ordinary, omitted and invalid limits must follow the agreed contract. Passing tests for this helper do not establish application-wide correctness.
import assert from "node:assert/strict";
import { firstEntries } from "./preview.js";
const entries = [10, 20, 30, 40];
assert.deepEqual(firstEntries(entries, 0), []);
assert.deepEqual(firstEntries(entries, 2), [10, 20]);
assert.deepEqual(firstEntries(entries), [10, 20, 30]);
assert.throws(() => firstEntries(entries, -1), RangeError);| Evidence | Observed result | Review decision |
|---|---|---|
| Zero-limit case on proposal | Returns three entries | Request a change |
| Zero, normal and default cases on repair | Match the contract | Check remaining boundaries |
| Negative and fractional limits | Rejected explicitly | Record the validation behavior |
| Callers and integration tests | Must be checked in the real repository | Approve only within the checked scope |
Leave a review comment the author can act on
Example comment: The zero limit currently falls through to the default. Please preserve zero, reject invalid limits and include the boundary assertions. I have checked the helper contract; the caller's error handling still needs verification. This states the defect, requested fix, evidence and remaining scope without claiming the whole system is safe.
Checklist
- Does the request define ordinary, omitted and invalid inputs?
- Did a focused test expose the defect in the proposed version?
- Does the repaired version pass that test and the adjacent boundary cases?
- Have callers, side effects and remaining review scope been recorded?
Practice loop
- 01Write the expected input, output and rejected values before reading the proposed explanation.
- 02Attach a failing boundary assertion, then rerun it with ordinary and invalid cases after the repair.
- 03Record which callers and side effects you checked and which still need review.
Limits of this page
This workflow organizes review evidence. It does not certify security, production readiness or developer competence. The actual repository, deployment context and risk determine the additional checks needed.
Source context
Published by Unrust as practical teaching material using public language documentation and original examples. See the scoring and editorial method for scope, checking and limitations.
Check your own starting point
One diagnostic session is a snapshot, not causal proof of why a result occurred. It can help you choose a focused next practice step without making a broader claim about your ability.
Take the free diagnostic