Free editable template
AI code review checklist
An agent can write a plausible patch and a test that repeats the same mistake. This checklist gives the reviewer a separate job: check the agreed behavior and keep the evidence for the version being reviewed.
Markdown (.md). No signup. Free to use, edit and share, including at work.
How to use it
- Save the commit or preview URL before you start. If the code changes during review, identify which checks need to run again.
- Run the main workflow and at least one failure case. Keep the actual output or recording beside the relevant checkbox.
- Compare the test list with the agreed checks. A skipped or missing test needs an explanation; a green summary does not answer that question.
- Write down the gaps before making a review decision. Leave an item unchecked when you do not have the evidence for it.
Open the file in any text editor, fill in the brackets, and paste it into your pull request or issue tracker. No attribution required.
Worked example
Example: a contact form that clears the message
- Expected behavior
- An invalid email shows a field error and keeps the message text.
- Review action
- Enter a message, enter an invalid email, and submit the form on the preview build.
- Observation
- The error appears, but the message is cleared. The happy-path test passed and never checked this case.
- Review decision
- Changes needed. Keep the acceptance criterion and repeat this case against the fixed build.
On-page ticks reset when you reload. Download a copy to keep your notes.
The full template
# Before you merge Use this checklist to review AI-assisted work. You do not need Ranex. Project: [name] Version reviewed: [commit, build or preview URL] Reviewer: [name] Date: [date] - [ ] Name the version you reviewed. Record the commit, build or preview URL. Make sure the checks refer to that version. Evidence / notes: [link or observation] - [ ] Try the promised result yourself. Use the feature as a visitor would. Record what happened, not just what the agent reported. Evidence / notes: [link or observation] - [ ] Try a case that should fail. Use missing input, an invalid value or a denied action. Check that the failure is handled clearly. Evidence / notes: [link or observation] - [ ] Inspect what the tests actually ran. Look for missing, skipped or changed tests. Ask why each changed, and keep the original acceptance criteria. Evidence / notes: [link or observation] - [ ] Check the nearby workflow. Try the next step and the way back. On a website, include a narrow screen and keyboard navigation. Evidence / notes: [link or observation] - [ ] Record what remains unchecked. Name the gaps and the person who will review them. Missing evidence is unfinished review. Evidence / notes: [link or observation] ## Review decision Decision: [ready for approval / changes needed / not enough evidence] Unresolved issues: [list] Next reviewer or action: [name and action] Completing this checklist is not a Ranex verdict or a guarantee of correctness. It records what a person checked and what remains unknown. --- From Ranex: https://ranex.dev/resources Free to use, edit and share, including in commercial projects. No attribution required.
Common questions
Can I use this if I cannot review the source code?
You can check the visible behavior, record the version and ask for evidence. Ask a qualified reviewer to cover code-level risks you cannot assess, such as permissions or data handling. Record those as open review items.
Does a completed checklist prove the code is safe?
No. It records the checks you performed. It cannot cover requirements or risks that were never checked, and it is not a Ranex gate verdict.
Keep the evidence with the work.
The template helps you describe and review the work. Ranex checks signed evidence against a policy for an exact version of the code.