Code Review Checklist Template

The change risk on the first task decides whether Phase 6 appears.

• Record the pull request link, the author and the change risk — Low, or High for authentication, payments, data migrations, infrastructure or permissions
• Keep the change small enough to review properly — Google’s guidance treats about 100 lines as usually reasonable and 1,000 as usually too large
• Separate refactoring from behaviour changes — a rename across 40 files hides the one line that matters
• Write a description that says what changed and why — linked ticket, what is out of scope, how to test it, screenshots for UI changes
• Read your own diff before requesting review — debug output, commented-out code and files that should not be there
• Request review only once CI passes — reviewers should not spend time on a build the pipeline will reject

• Check the change does what the ticket asks, and nothing else — unrelated edits go in their own pull request
• Walk the edge cases — empty and null input, boundaries, concurrency, retries, time zones and partial failure
• Check error handling fails safely — errors surface with context, nothing is silently swallowed, and failure denies rather than allows
• Check the design fits the codebase — logic in the right layer, no duplicated code, no abstraction without a second use
• Check compatibility of anything others depend on — public APIs, events, configuration and database schemas
• Ask a question when the intent is unclear — a guess in review becomes a wrong assumption in production

• Confirm tests cover the new behaviour — and, for a bug fix, a test that reproduces the original bug
• Check the tests would fail if the code were wrong — meaningful assertions, not coverage for its own sake
• Check error and edge paths are tested — not only the happy path the author ran by hand
• Look for flaky patterns — fixed sleeps, order-dependent tests and calls to real external services
• Check test data holds no real personal data or credentials — fixtures end up in logs and forks

• Check authorisation on every new endpoint and action — on the server, per object; Broken Access Control is still first in the OWASP Top 10:2025
• Check untrusted input is validated and output encoded — parameterised queries and no string-built commands; Injection is A05:2025
• Check no secrets or sensitive data reach code, config or logs — secret scanning catches known token formats, not every password
• Look for slow paths — N+1 queries, unbounded result sets, missing pagination and network calls without timeouts
• Justify every new dependency — maintained, needed and on an allowed licence; Software Supply Chain Failures is new at A03:2025

The decision is a required dropdown and the checklist halts until it is recorded. Changes requested shows the rework task.

• Check names and structure explain the code — comments say why, not what
• Mark optional comments as optional — Google’s guidance prefixes points of polish with “Nit:” so the author knows they can be ignored
• Check documentation moved with the code — README, API docs, runbooks, changelog and any decision record
• Record the review decision — Approved or Changes requested, with the blocking comments listed
• Author resolves each comment and requests review again — reply to every thread; fix it or explain why not

Tasks appear only when the change risk is High. The security reviewer records Approved or Not approved on the last task, and the checklist halts until they decide.

• Assign a second reviewer who knows the affected system — picked with the Members picker, not whoever is free
• Review against the relevant OWASP ASVS 5.0 requirements — authentication, session management, authorisation, and the new chapters on tokens and OAuth
• For data migrations, check the change is backward compatible — old code must keep working against the new schema until the release is complete
• For infrastructure changes, review the plan output as well as the code — Terraform plan, IAM wildcards and anything that destroys and recreates
• Confirm the rollback path — a feature flag, a revert or a documented manual step
• Record the security decision — Approved or Not approved, with conditions

• Confirm the required approvals and code owner reviews are in place — branch protection enforces them; the checklist records them for high-risk changes
• Get a fresh approval if commits were pushed after the last one — unless the repository already dismisses stale approvals
• Merge using the team’s convention — squash or merge commit, with a message that names the ticket
• Delete the branch and update the ticket — so nobody builds on a merged branch
• Hand the change to the deployment process — risky changes deploy behind a flag with a rollback plan