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,166 @@
+---
+name: cross-review
+description: >-
+  Перекрёстное ревью своей работы моделью другого семейства (Claude ↔ Codex):
+  линзы для ревьюера, способы запуска и разбор находок самим автором.
+  Применяй, когда пользователь просит независимое или перекрёстное ревью,
+  ревью другой моделью, или когда готовое изменение либо план стоит показать
+  чужим глазам до сдачи.
+---
+
+# Перекрёстное ревью
+
+Ты автор изменения и остаёшься его владельцем. Ревьюер из другого семейства
+моделей добавляет то, чего у тебя нет: свежая сессия не знает твоих
+рассуждений, а другое семейство замечает иные классы ошибок. Его отчёт —
+набор утверждений для проверки. Решения по ним принимаешь ты.
+
+Скилл даёт линзы, способы запуска и опыт разбора находок. Сколько линий
+запускать, какие линзы брать и нужна ли перепроверка, решай по задаче и цене
+ошибки.
+
+## Что передать ревьюеру
+
+Создай обменный каталог вне репозитория (`mktemp -d`) и напиши в нём
+короткое поручение `brief.md`. Если переменные shell не сохраняются между
+вызовами, дальше подставляй путь каталога целиком. В поручении:
+
+- **что проверять**: точная версия и способ её получить — diff-команда от
+  точки отсчёта, коммиты или пути. Ревьюер должен отличить проверяемое от
+  посторонних правок в дереве;
+- **постановка**: путь к задаче, спеке или критериям приёмки. Без неё линза
+  «по задаче» работает вслепую — так и напиши;
+- **команды проверки** и ожидаемый результат (например, число тестов);
+- **места, где ты сам не уверен** — вопросами, без своих обоснований:
+  пересказ твоей логики лишает ревьюера независимости;
+- **префикс находок** и **путь отчёта** (`REPORT`) — свои у каждого ревьюера.
+
+Поручение собирается конкатенацией: `cat brief.md prompts/mandate.md
+prompts/lens-….md > prompt.md`. Файлы `prompts/` лежат в каталоге этого
+скилла — там, откуда прочитан этот файл. Подставляй их как есть.
+
+## Линзы
+
+Линза — фокус ревьюера. Выбирай те, где в этом изменении правда может
+прятаться ошибка. Два ревьюера параллельно, с разными линзами, видят
+больше: у каждого свой контекст, и фокус не размывается. Один ревьюер с
+несколькими линзами дешевле.
+
+- [`lens-spec.md`](prompts/lens-spec.md) — **по задаче**: сделано ли то, что
+  просили, что упущено, что добавлено сверх, можно ли пройти критерии, не
+  решив задачу.
+- [`lens-code.md`](prompts/lens-code.md) — **по коду**: корректность,
+  инварианты, регрессии, безопасность, честность тестов.
+- [`lens-shape.md`](prompts/lens-shape.md) — **форма и вкус**: эскиз решения
+  до чтения diff, глубина модулей, запахи кода по Фаулеру.
+- [`lens-subtract.md`](prompts/lens-subtract.md) — **вычитание**: что можно
+  удалить без потери нужного поведения. Особенно полезна после нескольких
+  кругов исправлений и для моделей, склонных раздувать код.
+- [`lens-plan.md`](prompts/lens-plan.md) — **план или спека до реализации**:
+  документ судится на своём уровне.
+
+Ревьюеру нужна сильная модель с высокой глубиной рассуждения. У слабой
+модели больше ложных находок, и их разбор съедает экономию. Конкретные
+модели указаны в адаптерах запуска.
+
+## Как запустить
+
+Способ запуска зависит от среды. Механика каждого — в отдельном файле:
+
+- [T3 Code](references/launch-t3.md) — если доступны инструменты
+  `orchestrator_capabilities` и `delegate_task`. Удобнее всего: приложение
+  само следит за задачей и будит тебя по завершении.
+- [Codex из командной строки](references/launch-codex.md) — когда автор
+  Claude или другая модель.
+- [Claude из командной строки](references/launch-claude.md) — когда автор
+  Codex или другая модель.
+
+Общее для всех способов:
+
+- ревьюер получает **свежую сессию**, а не копию твоей истории;
+- ревьюер может то же, что ты: запускать тесты, ходить в сеть, создавать
+  временные файлы. Исходники и состояние защищает мандат в поручении.
+  Песочница только для чтения оставила бы ревьюеру одно чтение кода;
+- перед запуском сними `git status --porcelain`, после — сверь: дерево
+  должно остаться прежним;
+- пока ревьюер работает, проверяемые файлы не меняй, иначе он проверит
+  смесь двух версий. Правки, которые уже ясны, готовь рядом, во временном
+  каталоге;
+- если ревьюеров или кругов несколько, веди в обменном каталоге короткий
+  реестр: кто проверял, какую версию, id сессии или задачи, пути отчётов,
+  открытые ID. Он переживёт сжатие контекста и пригодится для отчёта;
+- код уходит к другому поставщику моделей. Просьба пользователя о
+  перекрёстном ревью покрывает проверяемое изменение и нужный ему контекст;
+  секреты и посторонние материалы в поручение не клади.
+
+## Разбор находок
+
+Разбирает находки автор: у тебя контекст кода и задачи. Пользователю нужен
+итог в отчёте, а не участие в каждом споре.
+
+По каждой находке проверь три вещи:
+
+1. **Верна ли она фактически.** Воспроизведи сценарий, прочти код, запусти
+   тест. Ревьюеры ошибаются уверенно: выдумывают API, путают версии,
+   приписывают коду то, чего в нём нет, требуют защиты от невозможных
+   состояний. Уверенный тон — не доказательство.
+2. **Применима ли к этому проекту** — его контрактам, масштабу, угрозам.
+3. **Соразмерна ли починка риску.** Предложенный способ — один из вариантов.
+   Подтверждённый дефект закрывай лучшим путём, какой видишь; отказ от
+   предложенной починки сам дефект не закрывает.
+
+Бывает и обратная ошибка: отмахнуться от неудобной находки. Отклонение с
+доводом от контракта или теста весит столько же, сколько исправление.
+Отклонение без довода ничем не лучше пропущенной находки.
+
+Следи за сложностью. Исправление, которое добавляет больше, чем убирает
+риска, — повод остановиться и поискать путь проще. Замечание о стиле без
+показанного вреда — не дефект.
+
+Исход каждой находки — один из четырёх:
+
+- `FIXED` — подтверждена и исправлена; названа проверка, которая это
+  показывает (по возможности — тест, воспроизводящий дефект);
+- `REJECTED` — не подтвердилась или неприменима; приведён довод;
+- `OUT_OF_SCOPE` — верна, но починка выходит за границы задачи;
+- `NEEDS_DECISION` — нужен выбор цели, устройства или допустимого риска.
+
+Последние два не решай молча правкой кода: вынеси пользователю с вариантами,
+их ценой и своей рекомендацией. Если без ответа дальше идти нельзя — спроси
+сразу, иначе — в итоговом отчёте.
+
+## Следующие круги
+
+Дороже всего в ревью — независимый контекст, который ревьюер набирает в
+первом заходе: устройство кода, постановка, свои опыты. Набирается он один
+раз. Все следующие круги отправляй в ту же сессию ревьюера:
+
+- **узкая перепроверка** — когда исправления нетривиальны или отклонение
+  могут оспорить. Отдай [`prompts/recheck.md`](prompts/recheck.md), путь к
+  своим резолюциям и что изменилось после ревью (diff-команду или список
+  файлов). Ревьюер проверяет только свои находки и оценивает, не вышла ли
+  починка шире нужного;
+- **полный проход по новой версии** — когда изменения вышли за пределы
+  починок. Опиши, что изменилось, и попроси пройти новую версию теми же
+  линзами; ID прежних находок сохраняются.
+
+Свежий ревьюер нужен, когда прежний контекст мешает: ревьюер держится за
+свои прошлые выводы, его сессия переполнена, его отчёт оказался слабым или
+нужен взгляд другой модели. Если способ запуска не умеет продолжать сессию,
+свежему ревьюеру дай пути к исходному поручению, отчёту и резолюциям, а
+сохранённые прежним ревьюером скрипты и фикстуры он возьмёт по путям из
+отчёта.
+
+Если спор повторяется без новых фактов, ещё один круг ничего не даст: реши
+сам с доводом или вынеси пользователю.
+
+## Отчёт пользователю
+
+Коротко и обычными словами:
+
+- кто смотрел (модель, глубина, способ запуска), какую версию и какими
+  линзами;
+- находки — по строке: ID, суть, исход; счётчики;
+- что исправлено и чем это проверено, что отклонено и почему;
+- что вынесено на решение пользователя;
+- пути к полным отчётам; затраты времени и денег, если они известны.