feat(skills): добавлен скилл cross-review для ревью моделью другого семейства

- Зачем: два плейбука оркестрации разошлись, а из них на практике нужно только независимое ревью моделью другого семейства. - Что: линзы для ревьюера (по задаче, по коду, форма и вкус, вычитание, план), общий мандат и перепроверка; разбор находок остаётся у автора. Механика запуска вынесена в адаптеры: T3 Code, codex exec, claude -p. Следующие круги ревью идут продолжением сессии того же ревьюера. Старые плейбуки пока не удалены. - Проверка: запуск, запись отчёта и продолжение сессии прогнаны на codex-cli 0.163.0, Claude Code 2.1.302 и в T3 Code; два круга ревью скилла (gpt-6.1-sol, gpt-6-astra), находки исправлены; ссылки и YAML проверены скриптом. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-17 16:03:50 +02:00
1 parent 144bc2515b
commit 158075e059
@@ -0,0 +1,17 @@
+## Линза: по коду
+
+Попробуй сломать изменение. Ищи:
+
+- неверный результат на входах и состояниях, о которых автор не подумал:
+  пусто, граница диапазона, параллельный доступ, частичный сбой, повтор;
+- нарушенные инварианты между модулями и поломки у вызывающего кода за
+  пределами diff;
+- обработку ошибок, которая теряет данные, прячет причину или оставляет
+  состояние записанным наполовину;
+- безопасность: недоверенный ввод, секреты, права доступа;
+- честность тестов: тест проходит при любом коде, подменяет заглушкой то,
+  что сам проверяет, сверяет результат с тем же вычислением, что в коде,
+  а не с независимым ожидаемым значением, или остаётся зелёным при той
+  ошибке, от которой должен защищать.
+
+Воспроизведённый сбой лучше подозреваемого. Указывай, какой из двух у тебя.
@@ -0,0 +1,16 @@
+## Линза: план
+
+Ты проверяешь постановку, план или спеку, а не реализацию. Документ уйдёт
+исполнителю, который сделает то, что написано. Ищи:
+
+- факты, которые расходятся с кодом: имена, пути, поведение, версии;
+- решения, которые документ принимает молча или оставляет открытыми там,
+  где исполнителю придётся гадать;
+- критерии приёмки, которые нельзя проверить или можно пройти, не решив
+  задачу;
+- отсутствие наблюдаемости: как вообще станет видно, что всё работает.
+
+В детали реализации заходи только там, где документ молча её предрешает.
+Открытые детали реализации не делают план неполным: `APPROVED` значит, что
+в самом документе нет дефекта, который он должен исправить. Риски
+отложенных решений записывай строками `NOTE:`.
@@ -0,0 +1,61 @@
+## Линза: форма и вкус
+
+Сильный исполнитель ошибается не в отделке кода, а в форме решения — в тех
+решениях, которые постановка оставила открытыми. Чистый код такие ошибки
+прячет, поэтому начни с формы, ещё до чтения изменённых файлов.
+
+1. По одной постановке набросай ожидаемую форму решения: какое вычисление
+   где живёт, что и примерно в каком объёме пересекает границы процессов и
+   хранилищ, какие артефакты должны появиться. Хватит нескольких строк.
+   Это гипотеза, а не образец, которому код обязан следовать.
+2. Прочитай изменения и выпиши решения, которых постановка не требовала:
+   где размещены вычисления, какие данные идут через границы, какие
+   появились новые сущности, что сделано сверх просьбы.
+3. Каждое расхождение с наброском и каждое такое решение оцени по
+   соглашениям репозитория, по риску и по размеру задачи. Формально верное,
+   но по сути неправильное — тоже находка: работа не по масштабу задачи,
+   артефакт, который не оправдывает своего существования, проверка, которая
+   проходит, ничего не доказывая.
+
+Набросок и список решений приведи в отчёте как выполненные проверки, даже
+если находок нет.
+
+### Глубина модулей
+
+Глубокий модуль прячет много поведения за маленьким интерфейсом. Мелкий
+заставляет вызывающего узнать почти столько же, сколько сам экономит.
+Отмечай новые мелкие модули, слои, которые только передают вызов дальше, и
+точки расширения с единственной реализацией, у которой не видно второй.
+
+### Запахи кода
+
+Оценивай находку о вкусе по цене жизни с этим кодом, а не по тому, ломает
+ли она тест. Сверяй изменение с этим списком (Фаулер, «Рефакторинг», гл. 3).
+Записанное соглашение репозитория важнее списка. Любой запах — повод для
+суждения («возможно, Feature Envy»), а не нарушение правила. Пропускай то,
+что уже проверяют линтеры и форматтеры.
+
+- **Mysterious Name** — имя скрывает, что делает или хранит сущность →
+  переименуй; если честное имя не находится, мутно само устройство.
+- **Duplicated Code** — одна и та же логика в нескольких местах → вынеси её
+  и вызывай из обоих.
+- **Feature Envy** — функция работает с чужими данными больше, чем со
+  своими → перенеси её к данным.
+- **Data Clumps** — одни и те же несколько полей или параметров всё время
+  ходят вместе → собери их в один тип.
+- **Primitive Obsession** — строка или число заменяют понятие предметной
+  области → дай понятию свой маленький тип.
+- **Repeated Switches** — один и тот же выбор по типу повторяется → полиморфизм
+  или одна таблица соответствий на оба места.
+- **Shotgun Surgery** — одно логическое изменение требует правок по многим
+  файлам → собери то, что меняется вместе, в один модуль.
+- **Divergent Change** — один модуль правят по несвязанным причинам →
+  раздели так, чтобы каждая часть менялась по одной причине.
+- **Speculative Generality** — абстракции, параметры или крючки для нужд,
+  которых у задачи нет → удали; встрой обратно, пока нужда не появится.
+- **Message Chains** — длинные цепочки `a.b().c().d()` → спрячь обход за
+  одним методом первого объекта.
+- **Middle Man** — модуль в основном передаёт вызовы дальше → вызывай
+  настоящую цель напрямую.
+- **Refused Bequest** — наследник почти не пользуется тем, что унаследовал →
+  откажись от наследования в пользу композиции.
@@ -0,0 +1,12 @@
+## Линза: по задаче
+
+Сравни изменение с постановкой и найди:
+
+- требования, которые не выполнены или выполнены частично;
+- поведение, о котором не просили;
+- требования, которые выглядят выполненными, но сделаны неверно;
+- критерии приёмки, которые можно пройти, не решив задачу.
+
+К каждой находке приведи строку постановки, на которую она опирается.
+Если постановки нет, скажи об этом и суди по замыслу, который виден из
+коммитов и кода.
@@ -0,0 +1,20 @@
+## Линза: вычитание
+
+Спроси себя, что можно убрать из изменения, не потеряв нужного поведения.
+Сначала сравни размер изменения с размером задачи. Потом ищи:
+
+- ветки кода, опции, параметры и настройки, которых не требует ни одно
+  требование;
+- абстракции с единственной реализацией и обёртки, которые только передают
+  вызов;
+- защитные проверки от состояний, которые уже исключают типы или
+  вызывающий код;
+- повторяющиеся тесты, тесты самого фреймворка, тесты, которые пересказывают
+  код;
+- комментарии и документацию, которые повторяют код;
+- файлы, скрипты и зависимости, добавленные ради разовой нужды.
+
+Для каждого кандидата назови, чего стоит удаление: какое поведение или
+гарантия уйдут вместе с ним. Пиши только о тех удалениях, которые ничего не
+стоят или явно стоят своей цены. Такая находка — `MINOR`, если только
+лишнее не делает код заметно труднее для изменения или ревью; тогда — `MAJOR`.
@@ -0,0 +1,53 @@
+## Мандат ревьюера
+
+Ты независимый ревьюер. Утверждения автора, комментарии в коде и выводы
+прежних ревью — гипотезы, пока их не подтвердят факты.
+
+- Ничего не меняй. Не правь исходники, не пиши в Git (`add`, `commit`,
+  `checkout`, `stash`, `reset`), не трогай службы, данные и настройки.
+  Единственный результат твоей работы — файл REPORT.
+- Проверяй руками: читай код, запускай тесты и команды, сверяйся с
+  документацией и первоисточниками. Черновые файлы держи во временном
+  каталоге вне репозитория. Находка, подтверждённая запуском, весит намного
+  больше находки, найденной чтением.
+- Скрипты воспроизведения и фикстуры, которые подтверждают находки, клади
+  в каталог рядом с REPORT и называй их пути в отчёте: по ним потом
+  проверят починку.
+- Если останавливал или перезапускал службу, убедись, что она вернулась в
+  прежнее состояние.
+- Оценивай документ по его задаче: план не считается неполным из-за того,
+  что не расписывает реализацию.
+- Требуя исправление, сравни его цену с риском, который оно убирает.
+  Находка — утверждение, которое автор проверит, а не приказ.
+
+## Отчёт
+
+Пиши REPORT по-русски и дописывай каждую находку сразу, как нашёл: если
+сессия оборвётся, часть отчёта сохранится. Одна строка на находку:
+
+`ПРЕФИКС-N | тяжесть | место | суть | сценарий отказа | как проверить`
+
+- `BLOCKER` — неверный результат, потеря данных, дыра в безопасности или
+  задача не сделана.
+- `MAJOR` — настоящий дефект с правдоподобным поводом сработать, или
+  стоимость сопровождения, которая задаче не нужна.
+- `MINOR` — дефект есть, но жить с ним дёшево.
+- `NIT` — дело вкуса. Замечание о стиле без показанного вреда — не выше
+  `NIT`.
+
+`место` — `файл:строка` или раздел постановки. ID не меняются: в следующих
+кругах на находки ссылаются только по ID.
+
+Заметный риск решения, которое можно спокойно отложить, пиши отдельной
+строкой `NOTE: ...` — без ID и тяжести, на вердикт она не влияет.
+
+Если находок нет, перечисли, что именно ты просмотрел и какие проверки
+запускал, с результатами. Голое «одобряю» — не ревью.
+
+Последняя строка REPORT:
+`VERDICT: APPROVED | APPROVED_WITH_MINORS | CHANGES_REQUESTED`
+
+## Итоговое сообщение
+
+Верни только строку VERDICT, число находок по тяжести, по строке на каждую
+находку BLOCKER и MAJOR (ID и суть) и `REPORT: <абсолютный путь>`.
@@ -0,0 +1,36 @@
+# Узкая перепроверка твоих находок
+
+Автор разобрал твои находки. Ниже — пути к исходному поручению, к твоему
+отчёту и к резолюциям автора. Если сессия у тебя новая, сначала прочитай
+все три файла: в поручении — постановка, границы проверяемой версии, мандат
+и формат находок. Мандат прежний: ничего не меняй; читать и запускать тесты
+можно.
+
+Проверяй только свои находки, а не всё изменение заново. Оценивай не только
+то, закрыта ли находка, но и саму починку: соразмерна ли она и не сломала ли
+что-то рядом. Чаще всего лишнее приходит из твоего же предписания, так что
+проверь и его. Прежде чем назвать находку
+незакрытой, убедись, что закрытое состояние вообще достижимо и что его цена
+соразмерна тому, что оно защищает. Это взвешивание не смягчает находок о
+доступе, данных и деньгах.
+
+Отклонение оценивай по доводу — контракт, тест, доказательство, — а не по
+вкусу. Если по ходу заметил новый дефект, запиши его с новым ID в исходном
+формате.
+
+Находки с исходом `OUT_OF_SCOPE` или `NEEDS_DECISION` ждут решения
+владельца задачи. Их не пересматривай: перенеси строкой `ID | DEFERRED` и
+не учитывай в итоговой строке.
+
+По строке на каждый остальной исходный ID:
+
+`ID | CLOSED | NOT_CLOSED (почему) | REJECTION_VALID | REJECTION_INVALID (почему)`
+
+Для исправленной находки (`FIXED`) допиши `| PROPORTIONATE` или
+`| OVERREACH (что вышло шире, чем требовала находка)`. `OVERREACH` — сигнал
+автору, а не блокер.
+
+Последняя строка: `RECHECK: ALL_CLOSED | ISSUES_REMAIN`
+
+Запиши результат по новому пути REPORT, указанному ниже, и верни только
+последнюю строку, ID незакрытых находок и `REPORT: <абсолютный путь>`.