dotfiles/agents/.agents/skills/cross-review/SKILL.md

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