deep-review

Deep Review от Iron-Ham — навык для комплексного code review, который разбирает изменения специализированными проверяющими по архитектуре, качеству кода, обработке ошибок, типам, комментариям, тестам, доступности, локализации, конкурентности, производительности, упрощению, безопасности и обнаружению утечек PII. Дополнительные проверяющие подключаются для конкретных стеков и платформ, включая Next.js, TypeScript, Python, SQL, Docker, Kubernetes, GitHub Actions, Terraform, Swift Data и другие направления из его таблицы аспектов. Это делает навык подходящим для ситуаций, где одной поверхностной проверки diff недостаточно и нужно разложить ревью по независимым классам риска. Область анализа задаётся явно. Флаг --pr или --branch определяет базовую ветку: навык ищет main, затем master или использует git merge-base, после чего получает список файлов и ближайшие зависимости. Флаг --changes охватывает незакоммиченные изменения в рабочем дереве и индексе. Путь в аргументе ограничивает проверку указанным каталогом или файлом. Если параметры не заданы, применяется поведение PR по умолчанию. Аспекты можно оставить core, выбрать отдельные code, errors, arch, types, tests, security, pii, a11y, perf и другие либо запросить full для всех сквозных направлений. Примеры включают ревью PR, ветки после завершения функции, локального diff перед коммитом и точечный анализ отдельного модуля. Отдельная сильная сторона — классификация результата. Проблема в добавленном или изменённом этим PR коде помечается [NEW], а проблема в неизменённом коде внутри области ревью — [PRE-EXISTING]. Навык прямо трактует обе категории как реальные проблемы: различие показывает происхождение, а не отменяет необходимость разобраться с находкой. Для архитектурного анализа используются карты зависимостей, поиск циклов, горячих мест, повторяющихся паттернов и вопросов масштаба; для типов изучаются инварианты и границы; для ошибок — тихие сбои и недостаточная обработка исключений. Отдельные направления позволяют сосредоточиться на доступности клавиатуры и screen reader, hardcoded-строках, гонках, утечках персональных данных, секретах, контроле доступа и других рисках. Платформенные направления выбираются по файлам и контексту проекта автоматически, а также могут быть включены явно: например, nextjs, ts, sql, infra, containers, github-actions, mobile или agent-instructions. При этом набор core и full не включает платформенные ревьюеры сам по себе, если релевантность не обнаружена и пользователь не запросил её напрямую. Такое разделение позволяет не запускать лишний анализ для несвязанного стека и одновременно расширить проверку, когда в изменениях действительно присутствует соответствующая технология. Для больших изменений полезно сначала задать область и аспекты, а затем отдельно проверить наиболее рискованные направления. Ограничения нужно учитывать при интерпретации результата. Навык анализирует заданную область и её непосредственные зависимости, поэтому неправильная базовая ветка, слишком узкий путь или отсутствующий контекст могут скрыть часть проблем. Классификация [PRE-EXISTING] не означает, что проблема безопасна или малозначима, а [NEW] не описывает автоматически приоритет исправления. Выбор full расширяет сквозные аспекты, но не добавляет все платформенные направления без обнаруженной релевантности. Для точного результата необходимо передать правильный scope-флаг или путь и выбрать аспекты, соответствующие коду; перечисление security, PII, a11y, concurrency или perf в команде не заменяет разбор конкретных находок и их подтверждение в исходниках.