--- 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, суть, исход; счётчики; - что исправлено и чем это проверено, что отклонено и почему; - что вынесено на решение пользователя; - пути к полным отчётам; затраты времени и денег, если они известны.