---
name: code-review
description: Applies team code review standards consistently across all reviews
version: 1.0.0
author: Your Name
tags:
  - engineering
  - code-review
  - development
  - quality
---

# Code Review Standards

> This skill helps AI apply your team's code review standards consistently.

## Instructions

When reviewing code, evaluate against these categories in order of priority:

### 1. Correctness (Blocking)
- Does the code do what it's supposed to do?
- Are edge cases handled?
- Are there any obvious bugs or logic errors?
- Do tests cover the happy path AND failure cases?

### 2. Security (Blocking)
- Is user input validated and sanitized?
- Are secrets/credentials properly handled (not hardcoded)?
- Is authentication/authorization correctly implemented?
- Are SQL queries parameterized?
- Is sensitive data encrypted at rest and in transit?

### 3. Performance (Blocking if Critical Path)
- Are there N+1 query problems?
- Is there unnecessary computation in loops?
- Are expensive operations cached appropriately?
- Could this code cause memory leaks?

### 4. Readability (Non-Blocking)
- Are variable/function names descriptive?
- Is the code self-documenting, or are comments needed?
- Is there dead code that should be removed?
- Are functions doing one thing well?

### 5. Maintainability (Non-Blocking)
- Is there code duplication that should be extracted?
- Are dependencies properly managed?
- Is error handling consistent with the codebase?
- Would future developers understand this code?

## Examples

### Good Review Comment
"This works, but the nested loops here give us O(n²) complexity. For our expected dataset size (~10k items), this could cause noticeable lag. Consider using a Map for O(n) lookup instead. Here's a sketch:
```javascript
const itemMap = new Map(items.map(i => [i.id, i]));
```
Not blocking, but worth considering before this hits production."

### Weak Review Comment
"This is slow, please optimize."
(Doesn't explain why or how)

### Unhelpful Review Comment  
"I would have done this differently."
(Doesn't provide actionable feedback)

## Best Practices

1. **Be specific** - Point to exact lines, explain the issue, suggest a fix
2. **Explain the "why"** - Help the author learn, not just fix
3. **Distinguish severity** - Label comments as blocking vs. non-blocking
4. **Praise good code** - Acknowledge clever solutions or clean implementations
5. **Ask questions** - "Is this intentional?" is better than assuming a bug
6. **Batch feedback** - Review the whole PR before commenting to avoid contradictions

## Review Checklist

Before approving, verify:

- [ ] Tests pass and cover new functionality
- [ ] No console.log/print statements left in
- [ ] Error messages are user-friendly
- [ ] API changes are documented
- [ ] Database migrations are reversible
- [ ] Feature flags wrap new functionality (if applicable)
- [ ] No TODO comments without linked tickets

## Comment Prefixes

Use these prefixes for clarity:

| Prefix | Meaning |
|--------|---------|
| `[blocking]` | Must fix before merge |
| `[nit]` | Minor suggestion, optional |
| `[question]` | Seeking clarification |
| `[suggestion]` | Alternative approach to consider |
| `[praise]` | Highlighting good code |

## Anti-Patterns

- **Bikeshedding** - Spending time on trivial style issues vs. real problems
- **Review bombing** - Leaving 50 comments at once without prioritization
- **Ghost approvals** - Approving without actually reading the code
- **Style policing** - Complaining about things a linter should catch
- **Scope creep** - Asking for unrelated changes in the same PR