Save this content to: .claude/skills/review/SKILL.md

# Skill: Review (Code Review)

**Версия:** 2026‑02‑02

Используй эту skill, когда нужно быстро и качественно провести **code review** в Laravel/PHP проекте.

## Когда использовать

- После запроса пользователя на ревью.
- Перед тем как сделать `git commit` (или сразу после него).
- Когда нужно найти регрессии, риски, потенциальные баги и нарушения Laravel‑конвенций.

## Принципы ревью

- **Сначала безопасность и корректность**, потом стиль и «красота».
- **KISS/DRY**, но без «паттерн ради паттерна». Улучшения должны снижать риск/сложность.
- **Laravel‑way:** предпочитай встроенные механизмы Laravel вместо самописного велосипеда.
- Не утверждай, что тесты/команды были выполнены, если у тебя нет реального вывода команд.

## Как проводить ревью

### 1) Сбор контекста (MUST)

1. Цель изменения (1–2 предложения): что добавили/починили.
2. Границы: что **не должно** измениться (публичные контракты, API, миграции и т.п.).
3. Какие риски допустимы? (например: «можно ли менять схему БД», «можно ли рефакторить»).

Если у тебя есть доступ к репозиторию/командам:
- посмотреть `git status`, `git diff`, `git diff --staged`;
- при необходимости — найти использования через `rg`/`grep`, проверить миграции.

Если доступа нет — попросить у пользователя diff/список файлов/контекст PR.

### 2) Чек‑лист (что проверить)

#### MUST FIX (блокирует merge)

- **Корректность:** логика соответствует задаче, нет явных багов/регрессий.
- **Валидация и безопасность:**
  - входные данные валидируются (FormRequest/Data-класс),
  - есть авторизация (Policy/Gate/`authorize()`),
  - нет mass-assignment проблем (`$fillable`/`$guarded`),
  - нет утечек секретов (логи, ошибки),
  - нет очевидных SQL-инъекций / XSS.
- **Стабильность:** корректная обработка `null`, исключений, конкурентных обновлений.
- **Транзакции:** если изменяются несколько сущностей/таблиц — подумать о `DB::transaction()`.

#### SHOULD FIX (желательно поправить)

- **Читабельность:** понятные имена, короткие методы, ранние возвраты.
- **Логи/observability:** адекватные логи ошибок, события/аудит если нужно.
- **Производительность/БД:**
  - N+1 (eager loading),
  - индексы под новые запросы,
  - выборка только нужных колонок,
  - кеширование (если реально нужно).
- **Конвенции Laravel:**
  - тонкие контроллеры,
  - доменная логика в сервисах/экшенах,
  - ресурсы/API ресурсы при отдаче JSON,
  - корректные FormRequest’ы/Data-классы.

#### NICE TO HAVE (опционально)

- Микро‑рефакторинг ради вкуса.
- Дополнительные абстракции без явного выигрыша.

### 3) Тесты (SHOULD)

Если изменения затрагивают бизнес‑логику/HTTP/БД:
- предложи **минимальный набор** тестов (Feature/Unit),
- укажи, что и где проверять,
- если проект на Sail — предложи запуск через `./vendor/bin/sail artisan test`.

### 4) Формат ответа (MUST)

Отдавай ревью структурированно:

1. **Summary** — 1–5 предложений: что сделано и общий вердикт.
2. **Critical (must fix)** — список блокеров.
3. **Warnings (should fix)** — важные улучшения.
4. **Suggestions (nice to have)** — улучшения по желанию.

Для каждого пункта:
- **Где** (файл/класс/метод)
- **Что не так**
- **Почему важно**
- **Как исправить** (конкретный пример/патч)

## Если просят «поправь»

- Делай **минимальный безопасный патч** (без избыточного рефакторинга).
- Если нужен более широкий рефакторинг — предложи отдельным коммитом/шагом.