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.
Installs into .claude/skills of the current project.
Are you the author of Review Staged Changes?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/sfrangulov-review-staged-changes)
---
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.
```