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

name, description

name	description
cross-review	Перекрёстное ревью своей работы моделью другого семейства (Claude ↔ Codex): линзы для ревьюера, способы запуска и разбор находок самим автором. Применяй, когда пользователь просит независимое или перекрёстное ревью, ревью другой моделью, или когда готовое изменение либо план стоит показать чужим глазам до сдачи.

Перекрёстное ревью

Ты автор изменения и остаёшься его владельцем. Ревьюер из другого семейства моделей добавляет то, чего у тебя нет: свежая сессия не знает твоих рассуждений, а другое семейство замечает иные классы ошибок. Его отчёт — набор утверждений для проверки. Решения по ним принимаешь ты.

Скилл даёт линзы, способы запуска и опыт разбора находок. Сколько линий запускать, какие линзы брать и нужна ли перепроверка, решай по задаче и цене ошибки.

Что передать ревьюеру

Создай обменный каталог вне репозитория (mktemp -d) и напиши в нём короткое поручение brief.md. Если переменные shell не сохраняются между вызовами, дальше подставляй путь каталога целиком. В поручении:

• что проверять: точная версия и способ её получить — diff-команда от точки отсчёта, коммиты или пути. Ревьюер должен отличить проверяемое от посторонних правок в дереве;
• постановка: путь к задаче, спеке или критериям приёмки. Без неё линза «по задаче» работает вслепую — так и напиши;
• команды проверки и ожидаемый результат (например, число тестов);
• границы, если они есть: куда не ходить (приватные данные, рабочие серверы, боевые скрипты), какие проверки слишком дороги, что в этой среде заведомо не находка;
• места, где ты сам не уверен — вопросами, без своих обоснований: пересказ твоей логики лишает ревьюера независимости. То же с выводами другого ревьюера, пока оба не закончили первый заход;
• префикс находок и путь отчёта (REPORT) — свои у каждого ревьюера.

Поручение собирается конкатенацией: cat brief.md prompts/mandate.md prompts/lens-….md > prompt.md. Файлы prompts/ лежат в каталоге этого скилла — там, откуда прочитан этот файл. Подставляй их как есть.

Линзы

Линза — фокус ревьюера. Выбирай те, где в этом изменении правда может прятаться ошибка. Два ревьюера параллельно, с разными линзами, видят больше: у каждого свой контекст, и фокус не размывается. Один ревьюер с несколькими линзами дешевле.

• lens-spec.md — по задаче: сделано ли то, что просили, что упущено, что добавлено сверх, можно ли пройти критерии, не решив задачу.
• lens-code.md — по коду: корректность, инварианты, регрессии, безопасность, честность тестов.
• lens-shape.md — форма и вкус: эскиз решения до чтения diff, глубина модулей, запахи кода по Фаулеру.
• lens-subtract.md — вычитание: что можно удалить без потери нужного поведения. Особенно полезна после нескольких кругов исправлений и для моделей, склонных раздувать код.
• lens-plan.md — план или спека до реализации: документ судится на своём уровне.

Ревьюеру нужна сильная модель с высокой глубиной рассуждения. У слабой модели больше ложных находок, и их разбор съедает экономию. Конкретные модели указаны в адаптерах запуска.

Как запустить

Способ запуска зависит от среды. Механика каждого — в отдельном файле:

• T3 Code — если доступны инструменты orchestrator_capabilities и delegate_task. Удобнее всего: приложение само следит за задачей и будит тебя по завершении.
• Codex из командной строки — когда автор Claude или другая модель.
• Claude из командной строки — когда автор Codex или другая модель.

Общее для всех способов:

• ревьюер получает свежую сессию, а не копию твоей истории;
• ревьюер может то же, что ты: запускать тесты, ходить в сеть, создавать временные файлы. Исходники и состояние защищает мандат в поручении. Песочница только для чтения оставила бы ревьюеру одно чтение кода;
• перед запуском сними git status --porcelain, после — сверь: дерево должно остаться прежним;
• пока ревьюер работает, проверяемые файлы не меняй, иначе он проверит смесь двух версий. Правки, которые уже ясны, готовь рядом, во временном каталоге;
• если ревьюеров или кругов несколько, веди в обменном каталоге короткий реестр: кто проверял, какую версию, id сессии или задачи, пути отчётов, открытые ID. Он переживёт сжатие контекста и пригодится для отчёта;
• код уходит к другому поставщику моделей. Просьба пользователя о перекрёстном ревью покрывает проверяемое изменение и нужный ему контекст; секреты и посторонние материалы в поручение не клади.

Разбор находок

Разбирает находки автор: у тебя контекст кода и задачи. Пользователю нужен итог в отчёте, а не участие в каждом споре.

По каждой находке проверь три вещи:

1. Верна ли она фактически. Воспроизведи сценарий, прочти код, запусти тест. Ревьюеры ошибаются уверенно: выдумывают API, путают версии, приписывают коду то, чего в нём нет, требуют защиты от невозможных состояний. Уверенный тон — не доказательство.
2. Применима ли к этому проекту — его контрактам, масштабу, угрозам.
3. Соразмерна ли починка риску. Предложенный способ — один из вариантов. Подтверждённый дефект закрывай лучшим путём, какой видишь; отказ от предложенной починки сам дефект не закрывает.

Бывает и обратная ошибка: отмахнуться от неудобной находки. Отклонение с доводом от контракта или теста весит столько же, сколько исправление. Отклонение без довода ничем не лучше пропущенной находки.

Следи за сложностью. Исправление, которое добавляет больше, чем убирает риска, — повод остановиться и поискать путь проще. Замечание о стиле без показанного вреда — не дефект.

Исход каждой находки — один из четырёх:

• FIXED — подтверждена и исправлена; названа проверка, которая это показывает (по возможности — тест, воспроизводящий дефект);
• REJECTED — не подтвердилась или неприменима; приведён довод;
• OUT_OF_SCOPE — верна, но починка выходит за границы задачи;
• NEEDS_DECISION — нужен выбор цели, устройства или допустимого риска.

Последние два не решай молча правкой кода: вынеси пользователю с вариантами, их ценой и своей рекомендацией. Если без ответа дальше идти нельзя — спроси сразу, иначе — в итоговом отчёте.

Резолюции пиши файлом в обменный каталог, по строке на находку: ID | исход | довод или проверка. Этот файл читает ревьюер в следующем круге, по нему же собирается отчёт пользователю.

Следующие круги

Дороже всего в ревью — независимый контекст, который ревьюер набирает в первом заходе: устройство кода, постановка, свои опыты. Набирается он один раз. Все следующие круги отправляй в ту же сессию ревьюера:

• узкая перепроверка — когда исправления нетривиальны или отклонение могут оспорить. Отдай prompts/recheck.md, путь к своим резолюциям и что изменилось после ревью (diff-команду или список файлов). Ревьюер проверяет только свои находки и оценивает, не вышла ли починка шире нужного;
• полный проход по новой версии — когда изменения вышли за пределы починок. Опиши, что изменилось, и попроси пройти новую версию теми же линзами; ID прежних находок сохраняются.

Свежий ревьюер нужен, когда прежний контекст мешает: ревьюер держится за свои прошлые выводы, его сессия переполнена, его отчёт оказался слабым, версия переработана так, что прежний контекст устарел, или нужен взгляд другой модели. Если способ запуска не умеет продолжать сессию, свежему ревьюеру дай пути к исходному поручению, отчёту и резолюциям, а сохранённые прежним ревьюером скрипты и фикстуры он возьмёт по путям из отчёта.

Если спор повторяется без новых фактов, ещё один круг ничего не даст: реши сам с доводом или вынеси пользователю.

Отчёт пользователю

Коротко и обычными словами:

• кто смотрел (модель, глубина, способ запуска), какую версию и какими линзами;
• находки — по строке: ID, суть, исход; счётчики;
• что исправлено и чем это проверено, что отклонено и почему;
• что вынесено на решение пользователя;
• пути к полным отчётам; затраты времени и денег, если они известны.