Templates · Engineering
Code review checklist template
What to check before approving a change
Start with this template →Sign in
Opens on reph with the template ready to start. No account needed; sign in to keep your document.
Filled example
The template filled in for a made-up company, so you can see what good looks like.
Review: rate-limit the password reset endpoint
Reviewer: Sofia Lindqvist · Date: 2026-06-03 · PR/Diff: northwind/web#4821
Change summary
Adds a per-email and per-IP limit (5 requests per 15 minutes) to POST /auth/reset, backed by the existing Redis bucket helper, and returns the same 202 response whether or not the address exists so the endpoint cannot be used to enumerate accounts.
Correctness
Tests
Security
Performance
Readability
Operability
Docs
Reviewer notes
Approved with two follow-ups owned by Kenji Watanabe: a warn log when the limiter fails open (SEC-221) and an auth_reset_limited_total metric (SEC-222), both due before the next release on June 10.
The template
Show the blank template
Code review checklist
Reviewer: [your name] · Date: [date] · PR/Diff: [link]
Change summary
What the change does and why, in the reviewer's own words. If you can't restate it, you haven't understood it yet.
Correctness
Tests
Security
Performance
Readability
Operability
Docs
Reviewer notes
Anything you approved with reservations, or asked the author to follow up on.
Questions
- Do I need to tick every box?
- No, mark items that do not apply as n/a so the next reader knows you considered them
- Who fills this in, the author or the reviewer?
- The reviewer, the author can pre-fill it as a self-review before asking
- What if I approve with reservations?
- Write them in Reviewer notes with an owner so they become follow-ups, not folklore
Fill it with your agent
Connect Claude to reph over MCP, then paste this. The draft arrives as suggestions you accept or reject section by section. How to connect Claude.
Find my reph doc "Code review checklist" with search_docs, then read it with read_doc. From the pull request diff, its description and the linked ticket, restate the change summary and tick or annotate each checklist item with the file and line behind your judgement. Never approve anything yourself. File it with suggest_edit, one replace_section op per section (heading line kept) so each can be accepted alone. Ask each open question (untested paths or missing rollback steps) with add_comment quoting that section's heading line, then call request_review with a one-line summary.
Related templates
RFC (request for comments)
A lightweight proposal circulated for comment before a decision: summary, motivation, proposal, alternatives, drawbacks and open questions, with a comment period and decision record
EngineerTech leadEngineering managerProduct managerDesign doc
Context, goals, proposed design, alternatives and rollout for a technical change
EngineerTech leadEngineering managerADR
Architecture decision record: one decision, its context and consequences
EngineerTech leadEngineering managerTechnical spec
Implementation-level spec: overview, goals, approach, milestones
EngineerTech leadAPI spec
Endpoints, request/response shapes, errors, auth and versioning
EngineerTech leadPull request description
What changed and why, the linked issue, how to test, screenshots, risk and rollback, and a reviewer checklist
EngineerTech lead
Start with this template →Sign in