Help me plan and complete a peer review task. I need actionable feedback that improves the work, respects the author, and fits the actual review scope. Do not invent defects, requirements, policy standards, or project context that I have not supplied. Item being reviewed: [WORK TO REVIEW] Review criteria or definition of done: [REVIEW CRITERIA] My role and review deadline: [ROLE AND DEADLINE] Known risks, constraints, and author context: [CONTEXT] First, turn the criteria into a prioritized review checklist. Separate blockers, important issues, and optional improvements. Distinguish a factual error, missing requirement, usability concern, maintainability concern, and personal preference; do not label preferences as defects. Then produce: 1. A time-boxed review plan that fits my deadline, including a first pass for scope and a final pass for regressions or consistency. 2. A checklist organized by priority, with concrete checks rather than broad labels. If this is code, include correctness, edge cases, tests, security or privacy implications, and documentation. If it is writing or design, adapt the checks to accuracy, audience, structure, accessibility, and acceptance criteria. 3. A feedback template with sections for blockers, questions, suggestions, and strengths. Each feedback item should explain the observed issue, impact, and a possible next step without dictating a solution when the owner should decide. 4. A final task list of what I must verify before approving, requesting changes, or escalating. Keep feedback specific and evidence-based. Do not rewrite the author's entire work unless I ask. If a required input is missing, ask up to 3 clarifying questions before drafting. Before answering, check that every review item maps to supplied criteria, a stated risk, or an explicitly marked assumption. Also check that the plan separates must-fix findings from non-blocking suggestions.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [WORK TO REVIEW] | Describe or paste the work, its purpose, and the parts you are responsible for reviewing. | A pull request adding CSV export to an internal customer-support dashboard, including API endpoint, UI button, and tests. |
| [REVIEW CRITERIA] | Paste acceptance criteria, rubric, requirements, standards, or the definition of done. | Export only records the current user can view; include active filters; CSV must open in Excel; show an error state; add tests for permissions and empty results. |
| [ROLE AND DEADLINE] | State your role, how much time you have, the due date, and the expected review outcome. | I am the second engineering reviewer. I have 45 minutes today and must approve, request changes, or leave a clear review before 4 p.m. |
| [CONTEXT] | List known risks, dependencies, prior decisions, author context, and constraints such as release timing or review scope. | The release is tomorrow. Customer names and email addresses are in the export. A similar export previously mishandled commas in addresses. |
How to use
- Paste the acceptance criteria before the work itself so the review remains tied to the intended outcome.
- Add the deadline and known risk areas; this lets the checklist prioritize instead of treating every concern equally.
- Use the feedback template only for observations you can point to in the work, tests, or requirements.
- Follow up with: "Convert these findings into concise review comments that state the impact and cite the relevant criterion."
Variations
Code Review
Use this for a pull request or code-change review.
Create a code review checklist for this change: [PR SUMMARY]. Acceptance criteria: [CRITERIA]. Relevant code or test notes: [CODE NOTES]. Constraints: [CONTEXT]. Produce a 30-minute review sequence and prioritized checks for correctness, authorization, input handling, error paths, backward compatibility, test coverage, and operational impact. For each likely finding, give a neutral comment pattern with observation, impact, and question or requested evidence. Do not infer bugs from absent code. Ask up to 3 questions only if a required input is missing. Flag assumptions and separate blockers from nits.
Document Review
Use this for a proposal, report, policy, or customer-facing document.
Plan a peer review for this document: [DOCUMENT]. Intended audience and decision: [AUDIENCE]. Required content or rubric: [RUBRIC]. Deadline and review scope: [DEADLINE]. Create a prioritized checklist for factual support, structure, audience fit, contradictions, terminology, accessibility, and actionability. Then draft feedback comments that quote or identify the exact section to address, explain the reader impact, and offer a next step. Do not fabricate sources or facts. Ask up to 3 questions only if needed. Check that each comment maps to the rubric or audience need.
Design Review
Use this for a product, UX, or visual design critique.
Help me conduct a design peer review. Design goal and user task: [GOAL]. Screens or flow being reviewed: [FLOW]. Constraints and acceptance criteria: [CRITERIA]. Known user or technical risks: [RISKS]. Produce a review path, a prioritized checklist for task completion, states, error recovery, hierarchy, accessibility, and responsive behavior, plus feedback comments grouped into blockers, questions, and suggestions. Do not claim usability-test findings unless I provide them. Ask up to 3 questions only if essential information is missing. Check that personal taste is clearly separated from evidence-based concerns.
Tips
- Review against the acceptance criteria before exploring improvements, because a polished suggestion cannot compensate for a missing requirement.
- Use blocker only when the issue prevents the intended user, release, safety, or agreed requirement from succeeding.
- A good review comment identifies the condition that triggers the problem; "this may break" is less useful than naming the input, role, screen size, or state.
- Save non-blocking polish for a separate section so the author can quickly see what is required for approval.
FAQ
Should I ask AI to find bugs in a peer review?
It can generate checks and help you reason about risks, but it cannot verify an issue without the work and context. Treat its suggestions as hypotheses to inspect.
How many comments should a peer review have?
There is no target number. Focus on material findings, unresolved questions, and the few improvements that meaningfully affect the outcome.
Can AI write my review comments?
Yes, if you give it your observed finding and criterion. Verify that the comment does not claim a test, user impact, or requirement you have not established.