---
name: review-staged-changes
description: Use when the user wants a review of currently staged git changes before committing. Triggers on phrases like "review staged", "посмотри что я застейджил", "review before commit", "проверь изменения перед коммитом". Returns a structured findings list focused on correctness, security, and conventions — not style nitpicks.
---

# Review Staged Changes

Скилл, который проверяет staged изменения в git и выдаёт findings до того, как пользователь сделает коммит. Это не полный код-ревью — это последний sanity check.

## Когда вызывается

- Пользователь явно просит: «отревьюй staged», «проверь что я застейджил», «review before commit».
- Перед формированием commit message (если есть отдельная команда /commit).

## Что делать

### 1. Собрать контекст

Запустить:
- `git diff --cached --stat` — обзор изменений.
- `git diff --cached` — сам diff.
- `git log -1 --format="%s"` — последний коммит для понимания контекста.

Если `--cached` пусто — сказать «нет staged изменений, нечего ревьюить» и закончить.

### 2. Прогнать структурированные проверки

Для каждого изменённого файла проверить:

**Безопасность (HIGH priority):**
- Захардкоженные секреты, API-ключи, токены, пароли, приватные ключи.
- `.env` файлы или их фрагменты в diff.
- SQL без параметризации (конкатенация переменных в строку запроса).
- Запуск процессов с shell-evaluation и user input.
- Небезопасная вставка HTML без санитизации.
- Динамическая исполнимая интерпретация строк с пользовательским вводом.

**Корректность (HIGH priority):**
- Удаление кода, который вызывается в других местах (быстрый grep на имя функции/класса).
- Изменение публичных API без обновления вызывающих мест.
- Изменение схемы БД без миграции.
- Удаление тестов без замены.

**Конвенции проекта (MEDIUM priority):**
- Проверить против `CLAUDE.md`, если есть в репозитории.
- Отладочные логи оставленные в коде.
- TODO/FIXME без issue ID.
- Закомментированный код вместо удалённого.

**Документация (LOW priority):**
- Изменён публичный API — обновлён ли README/docs?
- Новая env переменная — добавлена ли в `.env.example`?
- Новая зависимость — указана ли в package manifest и lockfile?

### 3. Не делать

- Не комментировать стиль форматирования (это работа линтера, не ревьюера).
- Не предлагать переименовать переменные без явного смысла.
- Не растягивать на «архитектурное ревью» — оставаться в scope staged diff.
- Не давать одобрение коммита — это решение пользователя. Только findings.

### 4. Формат вывода

```
## Staged review: <N> файлов, +X / -Y строк

### Блокеры (если есть)
- path/to/file.py:42 — [конкретная проблема]. [почему важно]. [как исправить]

### Стоит посмотреть
- path/to/file.ts:88 — [проблема и предложение]

### Что выглядит хорошо
- [1-2 конкретных позитива, не "good job overall"]

### Готов к коммиту?
- Да / Нет (с указанием блокеров)
```

Если блокеров нет — секцию «Блокеры» опустить, не писать «no blockers» отдельным пунктом.

### 5. Edge cases

- **Большой diff (>500 строк):** сообщить, что ревью будет на уровне «структурного обзора», не построчного. Сфокусироваться на безопасности и явных проблемах.
- **Только удаления:** проверить, что удаляемое не используется. `git grep` на ключевые имена.
- **Generated файлы (lockfile, build artifacts):** пропустить, упомянуть одной строкой «N generated файлов пропущено».
- **Бинарные файлы:** не пытаться ревьюить, упомянуть факт.

## Пример вывода

```
## Staged review: 3 файла, +127 / -14 строк

### Блокеры
- src/api/users.py:55 — конкатенация user_id в строку SQL.
  Возможна SQL injection. Использовать параметризованный запрос с плейсхолдерами и tuple аргументов.

### Стоит посмотреть
- src/api/users.py:88 — функция delete_user удалена, но в src/admin/dashboard.py:120 есть вызов.
  Либо обновить вызов, либо вернуть функцию.
- tests/test_users.py — нет нового теста на изменённую логику в users.py:55-70.

### Что выглядит хорошо
- Миграция 2026_05_add_users_email_index.py корректно индексирует столбец и обратима.

### Готов к коммиту?
Нет — пока не пофикшен SQL injection в users.py:55.
```