Pre-Merge Checklist
Before merging: ensure these.
What goes in the checklist
Tests: unit, integration, end-to-end where applicable. CI green.
Code review: at least one approver, ideally two for tier-1 services.
Documentation: comments on non-obvious code, runbook updates if behavior changed.
Observability: new metrics, alerts, dashboards added for the new feature.
Automate what you can
Branch protection rules in GitHub or GitLab block merges without review and CI.
PR templates require checking boxes for documentation, tests, observability.
Bots check that linked tickets are in the right state, that PR description meets the standard.
What humans must check
Logical correctness. Tests pass; the code may still be wrong.
API design. Breaking changes to public APIs need explicit acknowledgement.
Performance and security implications that automated tools miss.
Blockers vs nits
Blocker: must fix before merge. Test failures, security findings, breaking API changes without versioning.
Nit: nice-to-have, can be follow-up. Style preferences, naming, refactoring opportunities.
Distinguish them in review. "This is a blocker" vs "This is a nit" reduces friction.
How to roll out the checklist
Start with 3 items. Adding 20 items overwhelms reviewers and gets ignored.
Bake into PR template. Visible at PR creation, hard to skip.
Audit quarterly: pick 10 random merges, check the checklist quality. Adjust based on what slipped through.