text
| 1 | # Review Report Template |
| 2 | |
| 3 | Fill in and use as the final output of the workflow (printed, or posted per Step 6). |
| 4 | |
| 5 | ``` |
| 6 | ## PR Review: <title> (#<number>) |
| 7 | |
| 8 | **Risk tier:** High | Medium | Low |
| 9 | **Recommendation:** Merge as-is | Merge with changes | Needs discussion |
| 10 | |
| 11 | <1-paragraph summary of what this PR does and the overall verdict> |
| 12 | |
| 13 | --- |
| 14 | |
| 15 | ### Blockers |
| 16 | - `path/to/file.ts:42` — <what's wrong and why it matters> |
| 17 | **Fix:** <concrete suggestion> |
| 18 | |
| 19 | ### Major |
| 20 | - `path/to/file.ts:88` — <what's wrong and why it matters> |
| 21 | **Fix:** <concrete suggestion> |
| 22 | |
| 23 | ### Minor |
| 24 | - `path/to/file.ts:15` — <what's wrong> |
| 25 | **Fix:** <concrete suggestion> |
| 26 | |
| 27 | ### Nits (optional, non-blocking) |
| 28 | - `path/to/file.ts:5` — <style/naming/readability suggestion> |
| 29 | |
| 30 | --- |
| 31 | |
| 32 | ### Checklist summary |
| 33 | - Correctness: <pass / N findings> |
| 34 | - Security: <pass / N findings> |
| 35 | - Tests: <pass / N findings> |
| 36 | - Performance: <pass / N findings> |
| 37 | |
| 38 | ### Not reviewed |
| 39 | - <files skipped and why, e.g. generated/vendored/binary> |
| 40 | ``` |
| 41 | |
| 42 | ## Severity definitions |
| 43 | |
| 44 | - **Blocker** — must fix before merge: breaks correctness, introduces a security |
| 45 | vulnerability, or has no test coverage for critical new behavior. |
| 46 | - **Major** — should fix before merge: real bug risk, missing edge-case handling, |
| 47 | meaningful performance regression, or a maintainability hazard in shared code. |
| 48 | - **Minor** — should fix, can be a fast-follow: small correctness/readability issues |
| 49 | unlikely to cause incidents. |
| 50 | - **Nit** — optional: style, naming, formatting. Never blocks a merge on its own. |
| 51 | |
| 52 | ## Notes on tone |
| 53 | |
| 54 | - Point at the code and the consequence, not the author. "This throws on empty input" |
| 55 | reads very differently from "you forgot to handle empty input." |
| 56 | - Always pair a finding with a suggested fix — a comment that only says something is |
| 57 | wrong without a path forward slows the author down more than it helps. |
| 58 | - If everything looks good, say so plainly and briefly. A short "no blockers, two |
| 59 | minor nits" review is a complete review. |
| 60 |