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.