The Commit Checklist

Everything below happens before you hand the change off for review. Tick the boxes as you go; they persist when you reload the page. The reasoning behind each one is in The Lifecycle of a Code Change.

Check The Scope

• The change does one thing; if it does two, it's two changes
• No secrets in the diff: keys, tokens, passwords, a stray .env
• No accidents: build artifacts, generated files, large binaries, a debug branch you didn't mean to include
• Removed the scaffolding you added to get here: temporary logging, hardcoded values, a test you skipped "just for now"

Read It Yourself

• Read the whole change before your reviewer does, even if it's a single line
• Read it in the diff view, not your editor, because the diff is a different lens
• Hunt the usual suspects: a leftover debug print, a commented-out block, a variable renamed everywhere but one place, a function that quietly grew three arguments past where it should have split
• Read it like a stranger wrote it, especially when an agent did

Cover It With Tests

• Added or updated tests for this change, not just ran the ones that already passed
• The new test fails without your change, so you know it tests the thing
• Covered the error paths and the edges, not only the happy one
• Ran the feature yourself, with a real account or real input, not just a green pipeline

Write The Commit

• Subject: imperative, 50 characters or fewer, no trailing period
• Body: what and why, wrapped at 72 columns
• Footer: breaking changes and issue references
• Tested: trailer: how you convinced yourself it's correct, what you ran, logs or screenshots as proof, and what you deliberately did not test and why that was safe

Run The Presubmits Locally

• Linters and formatters, in check mode
• Static analyzers and type checkers
• Unit and integration tests
• Build and compile checks
• Code-coverage thresholds
• Security and dependency scans (SAST, vulnerable packages)
• License and policy checks

Open The Review

• A description that says what changed and why, written for the reviewer, not a paraphrase of the diff
• Screenshots, a clip, or a before and after for anything visual
• The issue or ticket linked
• Reviewers who actually have context, with a note on where you want the hardest look
• Self-review the diff on the platform first, and annotate the tricky parts before anyone has to ask

The fastest review is the one where the machine has already caught everything a machine can. Whatever is left is for the human.