engineering

Code Review Prompt

Lightweight quick code review template for fast feedback on small changes — covers correctness, safety, and readability in a single pass without full checklist overhead.

code-reviewprompt-engineeringai-promptsquick-review

Works well with agents

Code Reviewer Agent Frontend Engineer Agent Tech Lead Agent

Works well with skills

Bug Report Writing Code Review Checklist

$ npx skills add The-AI-Directory-Company/(…) --skill code-review-prompt

code-review-prompt/

SKILL.md

Markdown

1
2	# Code Review Prompt
3
4	## Before you start
5
6	Gather the following before reviewing:
7
8	1. What changed? — The diff or file(s) to review
9	2. Why did it change? — Link to ticket, bug report, or one-sentence explanation
10	3. What is the scope? — Quick fix, new feature, refactor, or dependency update
11	4. What should NOT change? — Existing behavior that must be preserved
12
13	If the reviewer cannot explain what the change does in one sentence, the PR description is insufficient. Request clarification first.
14
15	## Procedure
16
17	### 1. Classify the change size
18
19	Pick the review depth based on scope:
20
21	\| Change size \| Lines changed \| Review approach \|
22	\|-------------\|---------------\|-----------------\|
23	\| Tiny \| 1-10 lines \| Scan for correctness and typos. 2 minutes. \|
24	\| Small \| 11-50 lines \| Single-pass review. Check logic, errors, naming. 5 minutes. \|
25	\| Medium \| 51-200 lines \| Two-pass review. First pass for intent, second for details. 15 minutes. \|
26	\| Large \| 200+ lines \| Use the full code-review-checklist skill instead. \|
27
28	This skill is optimized for tiny-to-medium changes. For large changes, switch to the full code-review-checklist.
29
30	### 2. First pass — intent and safety
31
32	Read the entire diff once. Answer these questions:
33
34	1. Does this change do what the description says it does?
35	2. Does it change anything it should NOT change?
36	3. Are there obvious security issues? (user input used unsanitized, secrets exposed, auth bypassed)
37	4. Are there obvious correctness issues? (off-by-one, null access, wrong comparison operator)
38
39	If any answer is concerning, stop and flag it before continuing.
40
41	### 3. Second pass — details
42
43	Go through the diff line by line:
44
45	- Logic: Does each conditional and loop behave correctly at boundaries?
46	- Errors: Are failure cases handled? Are error messages specific?
47	- Naming: Do variable and function names describe their purpose?
48	- Duplication: Is new code duplicating existing utilities?
49	- Types: Are types correct and specific? (no unnecessary `any` or `object`)
50
51	### 4. Write the review
52
53	Use this format for each finding:
54
55	```
56	[SEVERITY] file.ts:LINE — DESCRIPTION
57
58	What: [what is wrong]
59	Why: [why it matters]
60	Fix: [specific suggestion]
61	```
62
63	Severity labels:
64	- BLOCK — Must fix. Bug, security flaw, or data loss risk.
65	- WARN — Should fix. Missing validation, poor error handling, performance issue.
66	- NOTE — Optional. Naming, readability, minor improvement.
67
68	### 5. Summarize
69
70	End the review with a one-line summary:
71
72	- Approve: "Looks good. No issues found."
73	- Approve with notes: "Approve — 2 optional suggestions, no blockers."
74	- Request changes: "Blocking on [N] issues: [brief list]."
75
76	## Quick review prompt template
77
78	Use this template when asking an AI to review code:
79
80	```
81	Review this code change. The change [DESCRIPTION OF WHAT IT DOES].
82
83	Focus on:
84	1. Correctness — does it do what it claims?
85	2. Safety — any security, null access, or data issues?
86	3. Edge cases — what inputs would break this?
87
88	For each issue found, state:
89	- Severity (BLOCK / WARN / NOTE)
90	- File and line
91	- What is wrong and how to fix it
92
93	If no issues, say "No issues found" — do not invent problems.
94
95	[PASTE DIFF OR CODE HERE]
96	```
97
98	## Quality checklist
99
100	Before submitting your review, verify:
101
102	- [ ] Every finding has a severity label
103	- [ ] BLOCK findings include a specific fix, not just "this is wrong"
104	- [ ] You checked for what is MISSING, not just what is present
105	- [ ] You did not invent issues that do not exist — false positives waste trust
106	- [ ] Your review matches the change scope — do not audit the entire file for a one-line fix
107	- [ ] Feedback is about the code, not the person
108
109	## Common mistakes
110
111	- Reviewing the entire file instead of the diff. A quick review covers WHAT CHANGED. Auditing unchanged code belongs in a separate task.
112	- Flagging style when there are bugs. If you see a correctness issue and a naming issue, lead with the correctness issue. Style feedback on buggy code is noise.
113	- Approving without understanding. "LGTM" without reading the diff is not a review. If you cannot explain the change, you cannot verify it.
114	- Inventing problems to seem thorough. Flagging non-issues erodes trust and slows the team. If the code is correct and clear, say so.
115	- Skipping the "what is missing" check. The most dangerous issues are not in the code that was written — they are in the validation, error handling, or edge case that was never added.
116	- Using this template for large changes. This is a quick review tool. Changes over 200 lines need the full code-review-checklist with section-by-section analysis.
117