Diff Reviewer

Conducts a rigorous, objective code review on a git diff. Flags logic errors, security vulnerabilities, leaked secrets, and broken conventions with exact line references.

1. Purpose

Identify defects in pull requests or staged commits before merging. Prioritizes correctness and security over stylistic opinions.

2. When to Use

Use this skill when:

• Reviewing a branch diff before merging (git diff main...feature).
• Inspecting staged changes prior to commit.
• User requests: "Review this diff" or "Check my changes".

3. When Not to Use

• Do not use to review pure infrastructure configuration files; use config-risk-reviewer.
• Do not use to apply code fixes; use minimal-bug-fix.

4. Required Inputs

• git_diff: Unified diff output (string).
• context_summary: Optional description of the goal of the diff.

5. Missing-Input Behavior

1. If git_diff is empty: report "Diff is empty; no changes to review."
2. If diff is missing line numbers: calculate relative to chunk headers (@@ -L,S +L,S @@).
3. Never invent defects if the diff is clean.

6. Procedure

Follow these numbered actions:

1. Action 1: Scan for Security Vulnerabilities and Leaks
   • Check for hardcoded credentials, unescaped SQL queries, command injections, and exposed debug logs.
2. Action 2: Check Logic Correctness and Edge Cases
   • Check null/undefined handling, off-by-one errors, unhandled promise rejections, and missing error branches.
3. Action 3: Check Backward Compatibility & Regressions
   • Verify that existing public signatures or data contracts are not broken.
4. Action 4: Classify Findings by Severity
   • BLOCKER: Security flaw, crash bug, or data corruption.
   • WARNING: Edge case bug, performance pitfall, or missing test.
   • NIT: Style, typo, or minor naming consistency.
5. Action 5: Emit Review Report
   • Format using Section 8.

7. Decision Rules

• If any secret or API key is found in diff: immediately classify as BLOCKER and recommend immediate credential rotation.
• If there are zero blockers or warnings: mark verdict as APPROVED. Otherwise mark CHANGES REQUESTED.

8. Output Format

Emit the review using this template:

### Code Review: [PR or Branch Title]

- **Verdict**: [APPROVED | CHANGES REQUESTED]
- **Files Changed**: [Count]
- **Blockers**: [Count] | **Warnings**: [Count] | **Nits**: [Count]

#### Findings Table
| File | Line | Severity | Category | Description & Fix Recommendation |
| :--- | :--- | :--- | :--- | :--- |
| `[file]` | `[line]` | **BLOCKER** | Security | [Exact issue and replacement code] |
| `[file]` | `[line]` | **WARNING** | Logic | [Edge case explanation] |

#### Positive Observations
- [Clean patterns or good test coverage observed in the diff]

9. Verification Checklist

• Every finding references exact file and line number.
• Findings are categorized by severity.
• No stylistic bike-shedding promoted to Blocker.
• Verdict accurately reflects presence of blockers.

10. Common Failures and Recovery

11. Stop or Escalation Conditions

Stop and ask the user when:

• Diff is too large (> 3,000 lines) to review accurately in one turn.

12. Examples

Example 1: Successful Execution

Input:

--- a/src/db.js
+++ b/src/db.js
@@ -10,3 +10,3 @@ function getUser(id) {
-  return db.query('SELECT * FROM users WHERE id = $1', [id]);
+  return db.query(`SELECT * FROM users WHERE id = '${id}'`);
 }

Output:

### Code Review: SQL Query Refactoring

- **Verdict**: CHANGES REQUESTED
- **Files Changed**: 1
- **Blockers**: 1 | **Warnings**: 0 | **Nits**: 0

#### Findings Table
| File | Line | Severity | Category | Description & Fix Recommendation |
| :--- | :--- | :--- | :--- | :--- |
| `src/db.js` | 11 | **BLOCKER** | Security | Critical SQL injection vulnerability. String interpolation allows arbitrary query execution. Revert to parameterized query: `db.query('SELECT * FROM users WHERE id = $1', [id])`. |

#### Positive Observations
- Query simplified, but security must take precedence.

Example 2: Ambiguous or Missing Input

Input:

Review this: (Empty diff)

Output:

### Code Review: Empty Diff

- **Verdict**: APPROVED (No Changes)
- **Files Changed**: 0
- **Blockers**: 0 | **Warnings**: 0 | **Nits**: 0

The provided diff contains no additions, modifications, or deletions.

Example 3: Expected Final Output

Output:

### Code Review: Add User Avatar Upload

- **Verdict**: APPROVED
- **Files Changed**: 2
- **Blockers**: 0 | **Warnings**: 0 | **Nits**: 1

#### Findings Table
| File | Line | Severity | Category | Description & Fix Recommendation |
| :--- | :--- | :--- | :--- | :--- |
| `src/upload.ts` | 42 | **NIT** | Style | Typo in comment: "avater" -> "avatar". |

#### Positive Observations
- MIME type and file size validation properly implemented before processing buffer.