differential-review

Этот навык предназначен для security-focused ревью изменений: pull request, commit или произвольного diff. Его задача — искать регрессии, появившиеся именно в изменении, но делать это с контекстом git-истории, оценкой радиуса воздействия, проверкой тестового покрытия и итоговым Markdown-отчётом. Подход начинается с риска, а не с размера патча: приоритет получают authentication и authorization, криптография, внешние вызовы и передача ценности. Для каждого вывода требуется доказательная опора — изменённые строки, история, конкретный сценарий атаки и честно обозначенный уровень уверенности. До анализа нужно провести pre-analysis и triage, определить размер кодовой базы и выбрать глубину. Для небольшой базы предлагается прочитать зависимости и использовать полный git blame, для средней — сфокусироваться на приоритетных файлах и зависимостях первого уровня, для большой — работать хирургически по критическим путям. Независимо от размера workflow включает анализ кода, проверку тестов, оценку blast radius, углублённый исторический контекст, adversarial-фазу для опасных изменений и формирование отчёта. Нельзя считать маленький PR безопасным только из-за числа строк, а рефакторинг — нейтральным без проверки инвариантов. В отчёте должны быть отражены все изменённые файлы, удалённый security-код и результат git blame, а для высокого риска — количественная оценка вызывающих или затронутых путей. Сценарии атаки формулируются конкретно, а не общими словами: нужно описать предпосылки, вход, нарушенный инвариант и ожидаемое последствие. Отсутствие тестов фиксируется как повышенный риск, а не как причина пропустить проверку. Особое внимание уделяется удалённым access-control модификаторам, исчезнувшей валидации, новым внешним вызовам без проверок и изменениям в security, CVE или fix-коммитах. При высоком blast radius и высоком риске требуется остановиться и провести более глубокое adversarial-моделирование. Практический результат — не устное резюме, а сохраняемый comprehensive markdown report, который можно передать дальше в issue-writer. В нём следует разделять найденные факты, ограничения покрытия и выводы; нельзя заявлять полный аудит, если была выполнена только поверхностная выборка. Навык также определяет границы применения: он не предназначен для greenfield-кода без базовой линии, документационных или чисто форматирующих изменений, а быстрый summary допустим только когда пользователь явно принимает сокращённую проверку. Для первой оценки можно использовать quick triage, но обязательные признаки качества — история, строки, attack scenarios, coverage limits и файл отчёта. Эта процедура помогает обнаружить security-регрессию до merge, однако не является гарантией отсутствия уязвимостей и не заменяет тестирование, threat modeling, ревью владельца системы или проверку runtime-конфигурации. Результат зависит от доступного diff, полноты git-истории, видимых тестов и выбранной глубины. Особенно осторожно нужно трактовать изменения, затрагивающие auth, crypto, деньги и внешние сервисы: там размер патча не снижает риск, а недостающий контекст должен повышать уровень внимания.