A Practical Review Checklist

Read the diff, not the chat

What matters is the diff, not the assistant's confident summary. Read every changed line, run the tests, and ask yourself: Does it solve the actual request? Does it do anything I did not ask for (extra files, config changes, deleted tests)? Could I explain every line to a teammate? If not, simplify it or learn it before you commit. Use git add -p to stage only the hunks you accept.

The checklist

Keep it short enough that you will actually use it every time.

[ ] Solves the request I actually made (and nothing extra)
[ ] Every new function / method / package exists (checked docs)
[ ] Tests pass; at least one fails if I break the code
[ ] Edge cases: empty, one, many, invalid input
[ ] No secrets, no string-built SQL / shell commands, no disabled checks
[ ] No unrelated edits (config, deleted tests, formatting churn)
[ ] I can explain each line to a teammate

Quick check: What should you review: the assistant's summary or the diff?

• The diff itself
• Only the summary
• Neither
• The commit time