Протокол инженерного ревью
Используется скиллом /plan для инженерного ревью перед планированием.
Определение размера
Авто-определяется из оценки сложности (шаг 1):
- 6+ баллов → BIG (полное ревью из 4 секций с паузами)
- 3-5 баллов → MEDIUM — используй SMALL-ревью, но отметь, если какая-то секция требует более глубокого взгляда
- 1-2 балла → SMALL (быстрое ревью, 1 вопрос на секцию)
Если авто-определённый размер ощущается неверным — скажи пользователю и предложи переопределить.
BIG-изменение — полное ревью
Пройди все 4 секции. После каждой секции — остановись и спроси обратную связь перед продолжением.
Для каждой найденной проблемы дай:
- Чёткое описание проблемы
- Почему это важно (конкретное следствие)
- 2–3 варианта (включая «ничего не делать», если разумно), для каждого:
- Усилия (Effort): low / medium / high
- Риск (Risk): low / medium / high
- Влияние (Impact): low / medium / high
- Стоимость поддержки (Maintenance cost): low / medium / high
- Твой рекомендуемый вариант и почему
Имей мнение. Не давай нейтральных сводок — давай вердикты.
Секция A — Ревью архитектуры
Оцени:
- Общий дизайн системы и границы компонентов
- Граф зависимостей и риски связанности (coupling)
- Поток данных и потенциальные узкие места
- Характеристики масштабирования и единые точки отказа
- Границы безопасности (auth, доступ к данным, лимиты API)
Выдели топ-3–4 проблемы. Затем:
«Ревью архитектуры готово. Одобряешь переход к ревью качества кода?»
Секция B — Ревью качества кода
Оцени:
- Структуру проекта и организацию модулей
- Нарушения DRY — агрессивно помечай дублирование
- Паттерны обработки ошибок и пропущенные edge cases
- Риски технического долга
- Места, которые over-engineered или under-engineered
Выдели топ-3–4 проблемы. Затем:
«Ревью качества кода готово. Одобряешь переход к ревью тестов?»
Секция C — Ревью тестов
Оцени:
- Покрытие тестами (unit, integration, e2e)
- Качество ассертов
- Пропущенные edge cases
- Сценарии отказа, которые не покрыты тестами
Выдели топ-3–4 проблемы. Затем:
«Ревью тестов готово. Одобряешь переход к ревью производительности?»
Секция D — Ревью производительности
Оцени:
- N+1 запросы или неэффективный I/O
- Риски использования памяти
- CPU-хотспоты или тяжёлые пути исполнения
- Возможности для кэширования
- Вопросы латентности и масштабируемости
Выдели топ-3–4 проблемы. Затем:
«Ревью производительности готово. Готов создать план задачи. Одобряешь?»
SMALL-изменение — краткое ревью
Один сфокусированный вопрос на секцию, без глубоких погружений:
- Архитектура: вписывается ли это в существующие паттерны или вводит новый?
- Качество кода: есть ли очевидные нарушения DRY или edge cases для обработки?
- Тесты: какое минимальное покрытие тестами здесь нужно?
- Производительность: есть ли очевидные узкие места для этого изменения?
Выведи краткую сводку, затем:
«Быстрое ревью готово. Готов создать план задачи. Одобряешь?»
Правила
- НЕ создавай никаких задач в БД, пока пользователь не одобрит после финальной секции ревью
- НЕ предполагай приоритеты — спрашивай, если неясно
- Предпочитай явные рекомендации нейтральным вариантам
- «Достаточно спроектировано» = не хрупко, но и не over-engineered