Software Engineer skill · code-review
Code review
What it does
Reviews a diff or code snippet for correctness bugs, security issues, readability and test gaps, and returns prioritised findings with line references and suggested fixes. Use it before requesting a human review or when reviewing a colleague's pull request.
- Time saved
- ~15–30 min per PR (estimate)
- Difficulty
- Intermediate
- Version
- v1 · 2026-10-01
What you give it
- Diff or code (no secrets) — e.g. function total(items) { let t; for (const i of items) t += i.price; return t }
- What the change is supposed to do — e.g. Sum item prices for the cart total.
- Team standards to apply (optional) (optional) — e.g. TypeScript strict; no any; tests for new logic
How it works
- Understand the intent from the context before judging.
- Look for correctness bugs first (off-by-one, null/undefined, error handling, concurrency), then security (injection, secrets, authz), then readability and tests.
- Reference exact lines or symbols for every finding.
- Suggest a concrete fix; keep nits separate and few.
- Say what tests would catch each bug.
- Don't flag style that a linter would handle unless standards say so. See references/review-checklist.md.
Output
Summary (1–2 lines) · Findings table: severity (blocker/major/minor/nit) · location · issue · suggested fix · Tests to add · Questions for the author.
Quality checklist
- ☑ Bugs before style
- ☑ Every finding located
- ☑ Concrete fixes
- ☑ No secrets in the input
Human check: A human reviewer still owns the approval; run the tests and read the code yourself.
Example (fictional)
- Diff or code (no secrets): function total(items) { let t; for (const i of items) t += i.price; return t }
- What the change is supposed to do: Sum item prices for the cart total.
Summary: one blocker — the total is never initialised.
| Severity | Location | Issue | Fix |
|---|---|---|---|
| Blocker | let t; | t starts as undefined, so the total is NaN | let t = 0; |
| Minor | loop | prices may be strings | validate or convert to numbers |
Tests to add: empty cart returns 0; two items sum correctly.
▶ Try it
Guests get 3 runs a day — sign in for more.Don't paste confidential or personal data.
Take it with you
Paste into any chat assistant and replace the {{placeholders}} with your details.
You are helping me with this task: Code review.
## Instructions
1. Understand the intent from the context before judging.
2. Look for correctness bugs first (off-by-one, null/undefined, error handling, concurrency), then security (injection, secrets, authz), then readability and tests.
3. Reference exact lines or symbols for every finding.
4. Suggest a concrete fix; keep nits separate and few.
5. Say what tests would catch each bug.
6. Don't flag style that a linter would handle unless standards say so. See references/review-checklist.md.
## Output format
**Summary** (1–2 lines) · **Findings** table: severity (blocker/major/minor/nit) · location · issue · suggested fix · **Tests to add** · **Questions for the author**.
## Before you answer, check
- Bugs before style
- Every finding located
- Concrete fixes
- No secrets in the input
If something important is missing from my inputs, say what you assumed. Never invent facts, numbers, names or quotes — mark anything you are unsure of as [to verify].
## My inputs
Diff or code (no secrets):
{{diff}}
What the change is supposed to do:
{{context}}
Team standards to apply (optional) (optional):
{{standards}}