review-staged-changes · git:20260606.f5f34ce · 2026-06-06 · sha256 9c88a1db63124738
review-staged-changes git:20260606.f5f34ceA
Immutable. This exact content never changes and is served at /api/v1/blob/9c88a1db63124738.
--- 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. ```