This free code review checklist sets one standard for authors and reviewers on every pull request or merge request. Engineering teams use it to agree what a reviewer checks by hand: correctness, tests, security, performance, readability, documentation and dependencies. It adds a second reviewer and a security review for high-risk changes, and it records the merge rules your repository enforces.
A review checklist that asks people to check indentation wastes the scarcest thing in the process, which is a reviewer’s attention. Split the work three ways. Anything a tool can decide runs in CI and blocks the merge on its own. Merge rules live in branch protection. Human reviewers get the questions only a person can answer: is this the right change, is it correct, and would the next engineer understand it.
Checks: formatting, lint, type checks, unit tests, build, known-vulnerable dependencies, licences, secret scanning.
Enforced by: required status checks.
Checks: intent, correctness, design, test quality, security logic, performance, readability and docs.
Enforced by: the reviewer, using an agreed standard.
Checks: number of approvals, code owners, re-approval after new commits.
Enforced by: GitHub branch protection or rulesets, GitLab approval rules.
Be clear about where the review itself happens. Comments, suggestions and approvals belong in GitHub or GitLab, next to the diff, and routine changes need nothing more than this standard pasted into the pull request template. CheckFlow is for the parts the platform does not hold: the written standard everyone signs up to, a gate with named approvers for high-risk changes, and a quarterly audit of whether review is working.
Seven phases follow a change from the author’s preparation to merge. The review decision halts the checklist until it is recorded, Changes requested adds a rework task, and a High change risk adds the high-risk gate in Phase 6.
The change risk on the first task decides whether Phase 6 appears.
The decision is a required dropdown and the checklist halts until it is recorded. Changes requested shows the rework task.
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.
A checklist nobody is forced to follow becomes optional by the third busy week. These repository settings make the important parts mandatory. Names are from GitHub and GitLab documentation as of 6 October 2026; several GitLab settings need a paid tier.
| What you want | GitHub | GitLab |
|---|---|---|
| No merge without review | Require a pull request before merging, with a set number of approvals | Approval rules with required approvals |
| Owners review their code | Require review from Code Owners, using a CODEOWNERS file in .github/, the root or docs/ | Code Owners as eligible or required approvers |
| Authors cannot approve themselves | Built in: a pull request author cannot approve their own pull request | Prevent approval by author, on by default |
| New commits need a new look | Dismiss stale pull request approvals when new commits are pushed | Remove all approvals when commits are added to the source branch |
| The last pusher is not the last approver | Require approval of the most recent reviewable push | Prevent approvals by users who add commits |
| Tools pass before people merge | Require status checks to pass | Pipelines must succeed |
| Dependency and licence policy | Dependency review action with an allow-licenses list | License approval policies (Ultimate tier) |
Two gotchas catch teams out. A CODEOWNERS file over 3 MB is not loaded at all, so code owners stop being requested without any warning on the pull request. And the dependency review action’s older deny-licenses option is deprecated, so new set-ups should list allowed licences instead.
Speed matters as much as rules. Google’s engineering practices say one business day is the maximum time to respond to a review request. SmartBear’s study of review at Cisco found reviewers lose effectiveness beyond 200 to 400 lines at a time or faster than about 500 lines an hour, which is another reason the checklist starts with keeping changes small.
Most pull requests never need CheckFlow. When the change risk is High, the gate appears: a second reviewer named with the Members picker, ASVS-based security tasks, and a security approval that halts the checklist until it is recorded, with the decision in the audit trail.
A recurring schedule opens a review audit each quarter. A table inside the audit task holds a sample of merged pull requests, with approvals, time to first review and size, so you can see whether the standard is followed or just published.
Tags separate teams and services, and a data set lists your repositories with their code owners and risk level. The phases double as the text of your pull request template, so the platform and the gate ask the same questions.
Review is one stage of shipping. The product side runs through the Feature Release Process Checklist, and the deploy and rollback through the Production Deployment & Rollback Checklist. Fixes found in review that point to a wider problem belong in the Bug Tracking & Resolution Checklist.
Infrastructure and permission changes that pass review still need change approval, which the IT Change Management Checklist covers. CheckFlow’s workflow software shows how approvals and conditional steps work across teams.
The questions only a person can answer: does the change do what the ticket asks, is it correct at the edges, do the tests prove it, is it secure, will it perform, can the next engineer read it, and did the docs move with it. Leave formatting, lint, type checks and known-vulnerable dependencies to CI, where they block the merge without anyone spending attention on them.
Small enough to review in one sitting. Google’s engineering practices call about 100 lines usually reasonable and 1,000 lines usually too large, and note that a change spread across many files is bigger than its line count suggests. SmartBear’s study at Cisco found defect detection drops beyond 200 to 400 lines per review session. Split refactoring from behaviour changes to get there.
One approval from someone other than the author is a common baseline, enforced by branch protection. Add a code owner review for owned paths, and a second reviewer plus a security review for high-risk changes such as authentication, payments, data migrations and infrastructure. More approvals on every change mostly add waiting time, so put the extra scrutiny where the risk is.
Three are useful. The OWASP Top 10:2025, released in November 2025, names the most common risk categories, with Software Supply Chain Failures and Mishandling of Exceptional Conditions new this edition. The Application Security Verification Standard 5.0, released in May 2025, gives testable requirements to review against. The OWASP Code Review Guide v2 explains how to run a manual security review.
No. Comments, suggestions and approvals should stay next to the diff, and branch protection should stay the thing that blocks a merge. CheckFlow holds the written standard, runs the gate for high-risk changes with named approvers and an audit trail, and runs the quarterly audit of how review is working in practice.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
