| 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.
