What this skill does
Applies a consistent, language-agnostic review framework to any code change. It evaluates code across five dimensions, produces prioritised findings with inline suggestions, and distinguishes blockers (must fix before merge) from improvements (worth addressing but not blocking).
When to use it
- User asks to "review this code", "review this PR", or "give feedback on this diff".
- User pastes a code snippet and wants quality feedback.
- User wants a second opinion before raising a PR.
- User needs a review checklist for a team standard.
Review dimensions
| Dimension |
What to check |
| Correctness |
Logic errors, off-by-one, null/undefined handling, edge cases not covered |
| Security |
Input validation, injection risks, secrets in code, insecure defaults, least-privilege violations |
| Maintainability |
Naming clarity, function/class size, duplication, coupling, missing or misleading comments |
| Performance |
N+1 queries, unnecessary allocations, blocking calls, inefficient algorithms for the scale |
| Test coverage |
Happy path covered, edge cases tested, negative scenarios present, test quality (not just count) |
Finding severity
| Severity |
Meaning |
Merge gate? |
| Blocker |
Must fix — correctness bug, security vulnerability, or missing critical test |
Yes |
| Major |
Should fix this PR — significant maintainability or performance issue |
Recommended |
| Minor |
Fix soon — small improvement, naming, formatting |
No |
| Nit |
Optional — style preference or very low impact |
No |
Instructions
Understand the context. What does this code do? What is the change trying to achieve? If not clear, state the assumption.
Review each dimension. Work through correctness → security → maintainability → performance → test coverage. Only flag genuine issues — do not manufacture findings.
Write inline suggestions. For each finding, reference the specific line or block and provide a concrete fix or alternative, not just a description of the problem.
Classify severity. Assign Blocker / Major / Minor / Nit to each finding.
Write an overall summary. Is this ready to merge? What is the dominant concern if any?
Produce the report using the output format below.
Output format
## Code review: [file name or PR title]
**Overall verdict:** Ready to merge / Merge after addressing blockers / Needs significant rework
**Summary:** [2–3 sentences: what the code does, overall quality impression, dominant concern.]
---
### Findings
#### [BLOCKER/MAJOR/MINOR/NIT] — [Short title]
**Location:** `file.ext:line` or `function name`
**Issue:** [What is wrong and why it matters.]
**Suggestion:**
\```language
// suggested fix or alternative
\```
---
### What works well
- [Specific thing done well — always include at least one]
- [Specific thing done well]
---
### Checklist
| Dimension | Status | Notes |
| --- | --- | --- |
| Correctness | Pass / Fail / Partial | |
| Security | Pass / Fail / Partial | |
| Maintainability | Pass / Fail / Partial | |
| Performance | Pass / Fail / Partial | |
| Test coverage | Pass / Fail / Partial | |
Examples
Example 1 — Security blocker in a web handler
Input: Python Flask route that concatenates user input into a SQL query string.
Expected output: Blocker finding for SQL injection with a parameterised query fix. Minor finding for missing input length validation. Checklist: Security Fail, Correctness Partial.
Example 2 — Clean PR with minor nits
Input: Well-structured TypeScript utility function with tests.
Expected output: No blockers or majors. Two Nit findings (variable naming, unused import). "What works well" section highlighting test coverage and clear function boundaries. Verdict: Ready to merge.
Notes
- Lead with blockers — a long list of nits before a blocker buries the most important information.
- Always include at least one "what works well" item. Reviews that only criticise reduce trust and miss knowledge-sharing opportunities.
- Do not flag style or formatting issues that a linter/formatter should enforce — note them once as "configure a linter" if they are pervasive.
- If the diff is too large to review in full, say so and ask the user to scope it (by file, by concern, or by risk area).
1---2name: code-review3description: Applies a consistent, language-agnostic review framework to any code change. It evaluates code across five dimensions, produces prioritised findings with inline suggestions, and distinguishes blockers (must fix before merge) from improvements (worth addressing but not blocking).4---56## What this skill does78Applies a consistent, language-agnostic review framework to any code change. It evaluates code across five dimensions, produces prioritised findings with inline suggestions, and distinguishes blockers (must fix before merge) from improvements (worth addressing but not blocking).910## When to use it1112- User asks to "review this code", "review this PR", or "give feedback on this diff".13- User pastes a code snippet and wants quality feedback.14- User wants a second opinion before raising a PR.15- User needs a review checklist for a team standard.1617## Review dimensions1819| Dimension | What to check |20| --- | --- |21| **Correctness** | Logic errors, off-by-one, null/undefined handling, edge cases not covered |22| **Security** | Input validation, injection risks, secrets in code, insecure defaults, least-privilege violations |23| **Maintainability** | Naming clarity, function/class size, duplication, coupling, missing or misleading comments |24| **Performance** | N+1 queries, unnecessary allocations, blocking calls, inefficient algorithms for the scale |25| **Test coverage** | Happy path covered, edge cases tested, negative scenarios present, test quality (not just count) |2627## Finding severity2829| Severity | Meaning | Merge gate? |30| --- | --- | --- |31| **Blocker** | Must fix — correctness bug, security vulnerability, or missing critical test | Yes |32| **Major** | Should fix this PR — significant maintainability or performance issue | Recommended |33| **Minor** | Fix soon — small improvement, naming, formatting | No |34| **Nit** | Optional — style preference or very low impact | No |3536## Instructions37381. **Understand the context.** What does this code do? What is the change trying to achieve? If not clear, state the assumption.39402. **Review each dimension.** Work through correctness → security → maintainability → performance → test coverage. Only flag genuine issues — do not manufacture findings.41423. **Write inline suggestions.** For each finding, reference the specific line or block and provide a concrete fix or alternative, not just a description of the problem.43444. **Classify severity.** Assign Blocker / Major / Minor / Nit to each finding.45465. **Write an overall summary.** Is this ready to merge? What is the dominant concern if any?47486. **Produce the report** using the output format below.4950## Output format5152```markdown53## Code review: [file name or PR title]5455**Overall verdict:** Ready to merge / Merge after addressing blockers / Needs significant rework5657**Summary:** [2–3 sentences: what the code does, overall quality impression, dominant concern.]5859---6061### Findings6263#### [BLOCKER/MAJOR/MINOR/NIT] — [Short title]6465**Location:** `file.ext:line` or `function name`6667**Issue:** [What is wrong and why it matters.]6869**Suggestion:**70\```language71// suggested fix or alternative72\```7374---7576### What works well7778- [Specific thing done well — always include at least one]79- [Specific thing done well]8081---8283### Checklist8485| Dimension | Status | Notes |86| --- | --- | --- |87| Correctness | Pass / Fail / Partial | |88| Security | Pass / Fail / Partial | |89| Maintainability | Pass / Fail / Partial | |90| Performance | Pass / Fail / Partial | |91| Test coverage | Pass / Fail / Partial | |92```9394## Examples9596### Example 1 — Security blocker in a web handler9798**Input:** Python Flask route that concatenates user input into a SQL query string.99100**Expected output:** Blocker finding for SQL injection with a parameterised query fix. Minor finding for missing input length validation. Checklist: Security Fail, Correctness Partial.101102### Example 2 — Clean PR with minor nits103104**Input:** Well-structured TypeScript utility function with tests.105106**Expected output:** No blockers or majors. Two Nit findings (variable naming, unused import). "What works well" section highlighting test coverage and clear function boundaries. Verdict: Ready to merge.107108## Notes109110- Lead with blockers — a long list of nits before a blocker buries the most important information.111- Always include at least one "what works well" item. Reviews that only criticise reduce trust and miss knowledge-sharing opportunities.112- Do not flag style or formatting issues that a linter/formatter should enforce — note them once as "configure a linter" if they are pervasive.113- If the diff is too large to review in full, say so and ask the user to scope it (by file, by concern, or by risk area).
MarieLynneBlock