---
name: code-review-protocol
title: Code Review Protocol
description: "Structured code review methodology that goes beyond \"looks good to me.\" Produces a severity-ranked finding list covering correctness, security, performance, maintainability, and design. Each finding includes the problem, why it matters, and a concrete fix suggestion. Catches what linters miss — logic errors, architectural drift, hidden coupling, and missed edge cases."
category: review
tags:
  - code-review
  - jakość
  - najlepsze-praktyki
  - pull-request
  - development
requires:
  - Claude
source: https://madejski.ai/skilloteka/code-review-protocol
locale: en
license: MIT
---

# Code Review Protocol

## What This Skill Does

Performs a structured, opinionated code review that catches what automated tools miss. The output is a severity-ranked list of findings — each with the problem, impact, and a concrete fix.

This is not a linting pass. It catches:
- Logic errors and missed edge cases
- Security vulnerabilities (injection, auth bypass, data exposure)
- Performance pitfalls (N+1 queries, unnecessary re-renders, memory leaks)
- Architectural drift (patterns inconsistent with the codebase)
- Hidden coupling and abstraction violations
- Error handling gaps (swallowed errors, missing validation)
- Race conditions and concurrency issues

## Severity Levels

| Level | Meaning | Action Required |
|-------|---------|-----------------|
| **CRITICAL** | Security vulnerability, data loss risk, or crash | Must fix before merge |
| **HIGH** | Bug, performance regression, or design violation | Should fix before merge |
| **MEDIUM** | Maintainability issue, missing edge case, or code smell | Fix now or create follow-up ticket |
| **LOW** | Style, naming, minor improvement | Nice to have |
| **NOTE** | Observation, question, or suggestion for discussion | No action required |

## Review Checklist

### 1. Correctness
- Does the code do what it claims to do?
- Are all edge cases handled? (null, empty, boundary values, error states)
- Are there off-by-one errors?
- Is the business logic correct?

### 2. Security
- Is user input validated and sanitized?
- Are there SQL/NoSQL injection vectors?
- Is authentication/authorization checked?
- Are secrets hardcoded?
- Is sensitive data exposed in logs, errors, or responses?

### 3. Performance
- Any N+1 query patterns?
- Unnecessary computation in loops or renders?
- Missing pagination on unbounded queries?
- Memory leaks (unclosed connections, growing collections)?
- Missing caching where it would help?

### 4. Error Handling
- Are errors caught and handled appropriately?
- Do error messages leak implementation details?
- Is there a fallback/retry for transient failures?
- Are async errors properly propagated?

### 5. Design and Architecture
- Does the change follow existing patterns in the codebase?
- Is there unnecessary coupling between modules?
- Are responsibilities clearly separated?
- Could this be simpler?

### 6. Testing
- Are there tests for the new/changed code?
- Do tests cover happy path AND edge cases?
- Are mocks realistic?
- Would a test failure point to the actual problem?

### 7. Readability
- Are names descriptive and consistent?
- Is the code self-documenting or does it need comments?
- Are functions small enough to understand at a glance?
- Is there dead code or commented-out code?

## Output Format

```markdown
## Code Review: {description}

### Summary
{1-2 sentence overview of the change and overall assessment}

### Findings

#### CRITICAL: {title}
**File:** `path/to/file.ts:42`
**Problem:** {what's wrong}
**Impact:** {why it matters}
**Fix:** {concrete suggestion with code}

#### HIGH: {title}
...
```

## Process

1. **Understand intent** — read PR description, linked issue, or ask what the change does
2. **Read the diff holistically** — understand the full change before commenting on details
3. **Apply checklist** — systematic pass through each category
4. **Rank findings** — severity determines action required
5. **Suggest fixes** — every finding includes a concrete fix, not just "this is wrong"
6. **Acknowledge good work** — call out well-written code too

## Anti-Patterns

- Nitpicking style when there are real bugs to catch
- "Looks good to me" without actually reading the code
- Rewriting the author's code in your preferred style
- Blocking on LOW findings
- Reviewing only the diff without understanding the context