QUICK ANSWER
What should a code review checklist include?
A code review checklist should inspect the change in context across correctness, tests, security, accessibility, performance, maintainability, and documentation. For each applicable check, record the review method, observed evidence, limitations, and result. Link every requested change to a finding, owner, due date, and verification evidence without treating checklist completion as merge approval.
A useful code review inspects one bounded change in context. It asks whether behavior is correct, tests can expose regression, trust boundaries remain controlled, affected interfaces stay usable, work stays bounded, the design remains maintainable, and documentation matches the change.
This original provider-neutral pack adds evidence, limitations, findings, owners, and follow-up to those questions. It does not replace author-supplied pull-request context, automated checks, specialist review, branch policy, merge authority, deployment, or production verification.
Inspect the change, record evidence, and close the loop
Use a consistent lens while adapting depth to risk. Technical facts and current project rules should outrank personal preference.
Freeze the review scope and read surrounding context
Record base and head references, affected areas, risk, and the author-owned change summary. Read every changed line plus complete affected functions and callers. Google Engineering Practices recommends considering design, functionality, complexity, tests, naming, comments, style, documentation, and broader system context.
Sources: [review-pack], [google-standard], [google-look], [github-reviews]
Trace correctness and test evidence through failure paths
Follow inputs, state changes, errors, retries, concurrency, and downstream effects. Inspect whether tests would fail when behavior breaks, cover relevant boundaries, and remain maintainable. A green check is evidence for its tested scope, not proof of the entire change.
Sources: [review-pack], [google-look], [nist-ssdf]
Add bounded security and accessibility review
For changed trust boundaries, inspect validation, authorization, data flow, secrets, logging, dependencies, abuse, and resource limits. For affected interfaces, inspect semantics, keyboard use, focus, errors, contrast, motion, target size, and reflow. Escalate when the change needs a specialist review; a diff checklist cannot establish full security or WCAG conformance.
Sources: [review-pack], [owasp-secure-review], [nist-ssdf], [wcag-22]
Inspect performance, maintainability, and documentation
Look for unbounded work, repeated I/O, allocations, queries, and measurable regressions, then inspect responsibilities, naming, complexity, comments, recovery, and relevant user, API, operational, migration, rollback, and monitoring notes. Separate required fixes from optional polish.
Sources: [review-pack], [google-standard], [google-look]
Link every finding to owned verification
Give each finding stable references, severity, a neutral statement, owner role, due date, and verification evidence. GitHub review states and repository rules can participate in merge decisions, but this template does not configure or grant that authority. The closed Draft 2020-12 schema checks structure while the validator checks reciprocity and safety.
Sources: [review-pack], [github-reviews], [json-schema-2020]
The code-review checklist owner boundary
This page owns reviewer inspection and evidence for one bounded change. Adjacent workflow owners remain separate.
Included
- Review scope, base and head references, repository alias, reviewer role, risk, changed areas, and lifecycle state
- Correctness, tests, security, accessibility, performance, maintainability, and documentation checks with methods, evidence, limitations, and results
- Reciprocal findings and owned follow-ups with due dates and verification evidence
- Editable Markdown, fictional JSON, closed schema, dependency-free validator, mutation tests, and deterministic ZIP
Not included
- Author-supplied pull-request description, acceptance context, screenshots, rollout plan, or PR-template ownership
- CI configuration, branch protection, rulesets, required reviewers, merge queue, merge action, approval authority, or repository administration
- Full threat model, penetration test, accessibility conformance audit, load test, legal or compliance review, deployment approval, or production smoke
- Any claim that checklist completion proves code correct, secure, accessible, performant, maintainable, approved, merged, or production-ready
DOWNLOADABLE RESOURCE
Download the code review checklist pack
Use the Markdown checklist for human review, the fictional JSON for a controlled record graph, the closed schema for structural tooling, and the validator for links, category coverage, evidence, states, owners, dates, and unsafe fields.
Code review checklist pack
An original review record connecting seven inspection categories to evidence, findings, owners, and verification follow-up.
Format: Editable Markdown, fictional JSON, closed JSON Schema, validator, tests, and deterministic builder in one ZIP
Locally reproduced August 1, 2026. SHA-256: 8d90b8b00fa437b964b1ab22c529f7c99a64cec2e8eed618f1eaf17b9474def4
Included
- Editable checklist and completed fictional seven-check JSON review
- Closed JSON Schema Draft 2020-12 contract for review, change set, checks, findings, and follow-ups
- Dependency-free validator and 25 positive and mutation tests for IDs, reciprocity, evidence, category coverage, states, dates, ownership, credentials, malformed input, and archive safety
- Fixed-timestamp exact-eight-file ZIP builder with source-byte parity and cross-time-zone reproduction checks
Verification boundary
The exact allowlist, source-byte parity, UTC and Pacific/Auckland rebuild identity, clean extraction, closed shapes, unique IDs, seven-category coverage, reciprocal check-finding and finding-follow-up links, evidence lengths, results, owners, dates, unsafe fields, credentials, malformed arrays, and em-dash prohibition were checked locally.
Three review shapes for different change risks
Reuse the evidence structure, not the fictional findings. Review depth should follow the actual change and system risk.
Stateful backend change
Use when: A change modifies validation, authorization, state transitions, retries, persistence, or side effects.
Trace commands through server boundaries, repeated and concurrent execution, durable mutation, logging, errors, and recovery, then demand tests that expose stale or duplicate behavior.
Structure
- Correctness and security checks tied to changed trust and state boundaries
- Failure, retry, concurrency, and recovery evidence with owned findings
Watch for: Diff inspection and local tests do not prove database isolation, production authorization, durable delivery, or incident safety.
Sources: [review-pack], [owasp-secure-review], [nist-ssdf]
User-interface change
Use when: A change affects content, controls, navigation, focus, validation, responsive layout, or perceived performance.
Inspect user intent, semantics, keyboard flow, focus, errors, reflow, contrast, motion, loading, failure recovery, and representative browser evidence.
Structure
- Correctness and accessibility checks for affected states and interactions
- Performance and test evidence with limitations across viewport and assistive-technology coverage
Watch for: A bounded component review cannot establish WCAG conformance, which applies through explicit conformance requirements including full pages.
Sources: [review-pack], [wcag-22], [google-look]
Documentation or configuration change
Use when: A small diff changes operating instructions, defaults, permissions, dependencies, deployment, or rollback behavior.
Compare the stated behavior with code and tests, inspect security and operational consequences, and make omitted verification or rollback evidence visible.
Structure
- Changed-context review beyond apparent line count
- Documentation, security, maintainability, and follow-up evidence
Watch for: A short diff can have broad impact; repository approval and automated checks remain governed by the actual platform and project policy.
Sources: [review-pack], [google-standard], [github-reviews], [json-schema-2020]
Decide whether the review record is ready for handoff
A complete record makes evidence and unresolved work visible. It does not authorize merge or release.
A result says pass but has no method, evidence, or limitation.
Choose: Change it to needs evidence or record the bounded inspection that supports the result.
Tradeoff: Review takes longer, but a checked box does not impersonate evidence.
A security or accessibility question exceeds reviewer expertise.
Choose: Record the boundary and assign a specialist follow-up instead of silently passing the category.
Tradeoff: The change may wait, but the checklist does not create false assurance.
A requested change has no owner or verification evidence.
Choose: Create a stable finding and reciprocal follow-up before closing the review record.
Tradeoff: Fewer comments disappear, but owners must spend time closing them with evidence.
All comments are resolved but repository rules or CI remain incomplete.
Choose: Leave merge and approval status to the configured repository owner; do not infer authority from this checklist.
Tradeoff: Review completion and merge readiness remain separate, which preserves accountable control.
START WITH THE ACTUAL DIFF
Download the checklist and replace every fictional record
Adapt the scope, categories, methods, evidence, limitations, findings, owners, and follow-up to the change your reviewers can inspect.
Download the code review checklistThe ZIP is locally reproduced. Public availability, real repository state, approval, merge, deployment, and production behavior remain unverified.
Document the API separatelyUse the API-documentation owner when the changed contract needs consumer-facing operations, schemas, examples, authentication, errors, and versioning.
Limits to review before adopting the checklist
A consistent checklist improves review visibility, but it cannot make evidence broader than the work actually performed.
- This original template does not reproduce another publisher's checklist or claim endorsement by Google, OWASP, GitHub, NIST, W3C, or JSON Schema.
- Google Engineering Practices describe Google review practices; teams must apply their own current contributing rules, ownership, risk, and escalation paths.
- OWASP and NIST sources support bounded secure-development review. This pack is not a threat model, secure-code-review certification, penetration test, or compliance assessment.
- WCAG 2.2 supports bounded inspection of affected web content, but a diff or component checklist does not establish full-page or product conformance.
- This ordinary informational article does not grant AI signup credits and does not prove correctness, security, accessibility, performance, approval, merge, or production readiness.
Primary guidance and verification sources
Current primary guidance supports the review lenses and boundaries without endorsing this editorial pack.
[review-pack] Playcode:Code review checklist pack
Checked August 1, 2026. Supports: The exact same-release original Markdown, fictional JSON, closed schema, validator, tests, and deterministic builder.
[google-standard] Google Engineering Practices:The Standard of Code Review
Checked August 1, 2026. Supports: Evidence over preference, code-health tradeoffs, review judgment, and escalation within Google practice.
[google-look] Google Engineering Practices:What to look for in a code review
Checked August 1, 2026. Supports: Design, functionality, complexity, tests, naming, comments, style, documentation, context, and complete diff inspection.
[owasp-secure-review] OWASP Foundation:Secure Code Review Cheat Sheet
Checked August 1, 2026. Supports: Current bounded manual security-review preparation, diff analysis, trust boundaries, data flow, business logic, and tool limits.
[github-reviews] GitHub:About pull request reviews
Checked August 1, 2026. Supports: Review comments, approve/request-changes states, and the separate effect of repository rules on merging.
[nist-ssdf] National Institute of Standards and Technology:NIST SP 800-218: Secure Software Development Framework 1.1
Checked August 1, 2026. Supports: High-level secure software practices including review and analysis integrated into an organization-owned SDLC.
[wcag-22] World Wide Web Consortium:Web Content Accessibility Guidelines 2.2
Checked August 1, 2026. Supports: Current testable web-content success criteria and the full-page conformance boundary.
[json-schema-2020] JSON Schema:JSON Schema Draft 2020-12
Checked August 1, 2026. Supports: The dialect and structural vocabulary declared by the included closed schema.
Code review checklist questions
What should a code reviewer check?
Inspect the change in context across intended behavior, failure paths, tests, security, affected accessibility, performance bounds, maintainability, and documentation. Record evidence and limitations for applicable checks, then connect requested changes to findings, owners, dates, and verification rather than relying on unchecked boxes.
Is a code review checklist the same as a pull request template?
No. A pull request template helps the author supply purpose, scope, testing, screenshots, rollout, and risk context. This checklist helps a reviewer inspect the resulting change and record evidence, findings, and follow-up. The two records should link without competing for ownership.
Can a checklist prove code is secure or accessible?
No. It can expose which bounded checks were performed and where specialist review is needed. Security may require threat modeling, scanning, manual secure review, testing, and operations evidence. Accessibility conformance follows the applicable WCAG conformance requirements and cannot be established from one diff checklist.
Does resolving every review comment approve a merge?
Not necessarily. Approval, required reviews, checks, branch protection, rulesets, merge queue, and merge authority are repository-specific controls. This template records reviewer findings and follow-up only. Consult the configured repository policy and accountable maintainers for the actual merge decision.
Does this code review checklist grant Playcode AI credits?
No. This is an ordinary informational resource and does not grant AI signup credits. Downloading it does not inspect code, run CI, approve a pull request, merge a branch, deploy software, or prove a production outcome.
BUILD FROM REVIEWED EVIDENCE
Turn an accepted change boundary into a working tool
Give Playcode the reviewed roles, records, states, rules, failures, and evidence after accountable owners resolve security, accessibility, policy, merge, and production decisions.
Explore internal tool buildingThis informational article does not grant AI signup credits. Playcode does not inspect, approve, merge, deploy, or guarantee your code or outcome.