# Code Review

> Use when the user asks to 'review this code', 'check my changes', 'review PR', 'audit' — and proactively after a non-trivial change or before opening, approving, or merging a PR, even unprompted. Reviews code for correctness, security, performance, and maintainability.

- Skill: `arozumenko/code-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add arozumenko/code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/arozumenko/code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: Apache-2.0
- Author: arozumenko (https://skillmd.com/u/arozumenko)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/arozumenko/code-review

---


# Code Review

Systematic code review focused on what matters. Not a style police — a correctness and risk checker.

## Review Scope

Determine what to review:

```bash
# Review staged changes
git --no-pager diff --cached

# Review working tree changes
git --no-pager diff

# Review a PR
gh pr diff <number>

# Review specific files
# Just read them directly
```

## Review Checklist

Check in this priority order. Stop at each category — don't rush to the next.

### 1. Correctness
- Does it do what it claims?
- Are edge cases handled (nulls, empty collections, boundary values)?
- Are error paths correct (not swallowed, not over-caught)?
- Do conditional branches cover all cases?

### 2. Security
- Input validation at system boundaries (user input, API responses)?
- SQL injection, XSS, command injection risks?
- Secrets in code or logs?
- Permissions and authorization checked?

### 3. Concurrency & State
- Race conditions in shared state?
- Proper locking/synchronization?
- Async operations awaited correctly?
- Resources properly closed/released?

### 4. Performance
- O(n^2) or worse in hot paths?
- Unnecessary allocations in loops?
- N+1 query patterns?
- Missing indexes for new queries?

### 5. Maintainability
- Is the intent clear from reading the code?
- Could someone unfamiliar modify this safely?
- Are there implicit assumptions that should be explicit?

## Output Format

Structure your review as:

```
## Summary
One sentence: what this change does and whether it looks good.

## Issues
### [Critical/Important/Nit] Title
File: path/to/file.py:42
Description of the issue and why it matters.
Suggested fix (if non-obvious).

## Questions
Things that aren't wrong but need clarification from the author.
```

Severity levels:
- **Critical** — will break in production, security vulnerability, data loss risk
- **Important** — correctness issue, significant performance problem, missing error handling
- **Nit** — style, naming, minor improvement (limit to 2-3 max, don't pile on)

## What NOT to Review

- Style preferences already handled by formatters/linters
- Adding type hints to code the author didn't change
- Suggesting refactors unrelated to the change
- Commenting on test structure unless tests are wrong