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.
Scanned 9/12/2026
Install to Claude Code
npx -y skills add aibot88/sec_skill_store --skill review-staged-changes --agent claude-codeInstalls 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 automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/aibot88-review-staged-changes)More formats (shields.io, HTML) on the badges page.
---
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.
```
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!