---
name: code-review-checklist
description: Code review methodology with severity levels. P0/P1/P2 classification, security checks, and deviation tracking — each with reasoning.
user-invocable: false
---
## Usage

Loaded automatically when its description matches the active task. The body below provides the working context.


# Code Review Checklist

Методология code review с приоритизацией по влиянию. Фокус на том, что реально влияет на пользователей и систему.

## Severity Levels

### P0 — Critical (блокирует деплой)
Проблемы, которые напрямую вредят пользователям или данным:
- **SQL injection, XSS, secrets в коде** — потому что это эксплуатируемые уязвимости
- **Потеря/повреждение данных** — потому что это необратимо
- **Сломанная бизнес-логика** — потому что пользователь получает неправильный результат
- **Бесконечные циклы, утечки памяти** — потому что это роняет production
- **must_haves truth = FALSE** — потому что основная цель задачи не достигнута

### P1 — Warning (стоит исправить)
Проблемы, которые ухудшают поддерживаемость и устойчивость:
- **Отсутствие error handling** — потому что unhandled errors приводят к непонятным ошибкам у пользователей
- **Дублирование кода** — потому что баг в одном месте придётся искать во всех копиях
- **Нарушение паттернов проекта** — потому что непоследовательный код замедляет всю команду
- **Файл превышает лимит** — потому что большие файлы сложнее ревьюить и поддерживать
- **must_haves truth = PARTIAL** — потому что часть цели не реализована

### P2 — Info (для справки)
Наблюдения, которые можно учесть в будущем:
- Стилистические несоответствия
- Возможные улучшения

## Процесс ревью

1. **Что изменилось**: `git diff HEAD~N`, `git log --oneline -10` — общая картина
2. **Безопасность**: SQL injection, XSS, exposed secrets, unsafe inputs — потому что это самый критичный вектор
3. **Цель задачи**: код делает то, что задумано? Сравни с описанием задачи
4. **Edge cases**: обработаны ли граничные случаи? Особенно null/undefined, пустые массивы, сетевые ошибки
5. **Deviation tracking**: кодер применил auto-fix правильно? Исправления в scope текущей задачи?
6. **Размер файлов**: проверь по `file-size-limits` skill
7. **Verdict**: `approved: true/false`

## Принципы оценки

- Фокусируйся на реальном влиянии: безопасность → достижение цели → корректность → стиль, потому что этот порядок отражает приоритет для пользователей
- Если код работает и build зелёный — ищи реальные проблемы, а не стилистические придирки, потому что nitpicking замедляет pipeline без пользы
- P0 findings → automatic reject. P1 findings → reject если их больше 2. P2 — информационно
- must_haves FALSE = automatic reject, потому что цель задачи — первичный критерий успеха