requesting-code-review

Requesting Code Review

Before you ask the user to look at your work, do a self-review. Catch the embarrassing stuff yourself.

Checklist (run all of these)

• Tests pass. Run the suite. Quote the output. (Invoke verification-before-completion.)
• No debug code. No print, console.log, dbg!(), commented blocks, or temporary // REMOVE markers.
• No TODOs you introduced unless they're tracked elsewhere.
• Scope matches the plan. No accidental drive-by changes.
• No secrets. Scan the diff for tokens, keys, passwords. Check .env files weren't staged.
• Imports are clean. No unused imports, no commented imports.
• No dead code. No functions/variables you defined but didn't use.
• Commits are logical. If a single commit mixes unrelated changes, split it before review.
• The diff reads top-to-bottom. Open it and read like a stranger. Anything that needs explanation should already have a comment.

Then summarize

After the checklist, write a short summary to give the reviewer:

• What changed in 1–3 bullets.
• What to focus on (the parts most worth scrutiny).
• What you're unsure about — call out judgment calls so the reviewer knows to weigh in.

Anti-patterns

• Asking for review while tests are red.
• Asking for review with debug code still in the diff.
• "Looks good to me" self-reviews that don't run the checklist.
• Sending a 2000-line diff with no summary.

Done

After running the checklist and writing the summary, hand off cleanly to the user (or open the PR with the summary in the description).