| name | code-review |
| version | 1.1 |
| description | Performs systematic, multi-dimensional code review covering correctness, security, performance, maintainability, and style. Produces actionable, prioritised findings with evidence-based recommendations. Use when asked to review code, audit a pull request, or evaluate implementation quality. |
Skill: Code Review
When Not to Use
- When the task is exploratory prototyping and code quality standards have been explicitly deferred
- When the request is to write or refactor code rather than evaluate existing code — use a separate authoring pass first, then apply this skill
- When a superficial style-only lint pass is sufficient — this skill performs deep multi-dimensional review, not surface formatting
Interaction Protocol
Before starting, ask if not already clear:
- What is the intended purpose of the code — what should it do, and in what context does it run?
- Are there specific concerns to prioritise (security, performance, correctness, readability)?
- What language, framework, and conventions apply?
Output style:
- Group findings by dimension (correctness, security, performance, maintainability, style)
- Assign each finding a severity:
Critical, High, Medium, Low, or Info
- For every finding: state the problem, identify the exact location, explain the consequence, and provide a concrete recommended fix
- Do not pad with praise; observations that do not identify a problem or produce an actionable recommendation are not findings
- End with a summary: total findings by severity, and an overall assessment
Inputs and Outputs
Input: Source code (any language), with optional context: purpose, language/framework, prior review notes, specific concerns
Output: Structured findings grouped by dimension, each with severity, location, problem statement, consequence, and recommendation; overall summary
Composability: Use after research (to understand the problem domain); use before strategy-author (to translate findings into architectural decisions); combine with citation-discipline when recommending standards or citing specifications
Purpose
Produce rigorous, evidence-based code review that identifies real problems and produces actionable recommendations. Every finding must be grounded in observable code behaviour, known failure modes, or established standards — not preference or convention for its own sake.
1. Review Dimensions
Apply all dimensions in sequence. Do not skip a dimension because no issues are expected.
1.1 Correctness
- Does the code do what it is intended to do?
- Are there logic errors, off-by-one errors, or incorrect conditions?
- Are edge cases and boundary conditions handled?
- Is error handling present, appropriate, and complete?
- For every
except (or equivalent catch) clause, verify the caught type exists in the library's published exception hierarchy; catching a type outside that hierarchy is a defect.
- Verify that no
except clause catches a parent type that masks more specific errors when a narrower type is available.
- Flag any
except Exception (or language-equivalent catch-all) that lacks explicit written justification at the call site explaining why no narrower type is appropriate.
- Are there race conditions or concurrency hazards if the code runs in a concurrent context?
- Are external assumptions (API contracts, data formats, invariants) explicitly validated?
1.2 Security
- Are all external inputs validated, sanitised, and bounds-checked before use?
- Is authentication and authorisation enforced at every access point?
- Are secrets, credentials, and sensitive values never hardcoded or logged?
- Are cryptographic operations using approved, current algorithms and libraries?
- Are there injection risks (SQL, command, template, path traversal)?
- Is error output safe — does it avoid leaking internal state, stack traces, or sensitive data?
- Are dependencies at known-safe versions?
1.3 Performance
- Are there O(n²) or worse algorithms where a better complexity is practical?
- Are there unnecessary database queries, network calls, or I/O operations inside loops?
- Are expensive resources (connections, file handles, threads) properly pooled and released?
- Are there memory leaks or unbounded growth patterns?
- Is caching used where appropriate, and invalidated correctly?
1.4 Maintainability
- Is the code's intent clear without requiring deep context to understand?
- Are functions and methods focused on a single responsibility?
- Is duplication present where abstraction would reduce risk?
- Are names — variables, functions, classes, files — accurate and unambiguous?
- Are dependencies and coupling minimised?
- Is the code testable as written, or do structural changes improve testability?
1.5 Style and Conventions
- Does the code follow the established conventions for this language and codebase?
- Are comments present where the logic is non-obvious, and absent where the code is self-evident?
- Is formatting consistent with the project's style?
2. Severity Classification
Assign each finding one of the following:
| Severity | Criteria |
|---|
Critical | Defect that will cause data loss, security breach, or system failure under expected conditions |
High | Defect likely to cause incorrect behaviour, vulnerability, or significant degradation in realistic scenarios |
Medium | Defect that may cause problems under specific conditions; technical debt with meaningful risk |
Low | Minor issue with limited practical impact; style or convention violation with a clear rationale for change |
Info | Observation or suggestion that does not represent a defect; context for the author |
3. Finding Format
Each finding must contain:
**[SEVERITY] Dimension — Short title**
Location: <file>, <function/method/line>
Problem: What is wrong and why it is wrong.
Consequence: What fails or degrades if this is not addressed.
Recommendation: Specific change to make, including example code where helpful.
4. Consistency Check
Before finalising, verify:
- Every finding has a concrete location — no vague "the code does X" statements
- Every recommendation is actionable — no "consider improving" without specifying how
- Severity levels are consistent — a
Critical finding in one section is not treated as Low elsewhere for the same class of issue
- No dimension has been omitted
- Summary counts match the body
5. Failure Modes
- Flagging style preferences as correctness issues
- Assigning
Critical severity to findings without demonstrating a concrete failure path
- Producing findings without a recommended fix
- Missing security issues because the focus was on style
- Generating praise sections that dilute the signal of the findings
