> ## Content Index
> Fetch the complete content index at: https://starikov.co/llms.txt
> Use this file to discover other available public pages before exploring further.

# The Commit Checklist
- URL: https://starikov.co/commit-checklist/
- Published: 2026-07-14T13:00:31.000Z
- Updated: 2026-07-14T13:00:31.000Z
- Description: The unglamorous gate between "works on my machine" and "someone else has to read this."
- Author: Illya Starikov
- Tags: AI, Software Engineering, AI Generated

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](https://starikov.co/commit-lifecycle/).

## 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.