Codex Audit

codex-audit

Скилл для делегирования в codex CLI на этой машине задач, требующих другой модели как независимого второго взгляда, без права что-либо менять в репо (read-only). Codex изолирован: не видит контекст текущей сессии Claude, но читает файлы репозитория. Ценность не в том, что он "умнее" - а в разнообразии мышления: другая модель ловит другие классы ошибок, чем основной агент.

Режимы

| Режим | Когда | Effort | Формат ответа Codex | Файлы в docs/dev/ | |---|---|---|---|---| | audit (дефолт) | глубокий разбор кода/диффа/плана; "отправь на аудит", "пусть codex проверит" | high | по каждому вопросу вердикт ok / risk / blocker + 1-2 предложения | audit-plan- / audit-report- | | adversarial | состязательное ревью со скептической позицией; "сломай решение", "состязательное ревью", "попробуй сломать через codex" - нужно не подтверждение, а активный поиск дыр | high | по каждому компоненту: чем и при каких условиях сломается; "проблем нет" - только с перечнем проверенных атак | adversarial-plan- / adversarial-report- | | second-opinion | независимый взгляд на подход/решение/дифф; "второе мнение", "посоветуйся"; по умолчанию после крупной работы | medium | согласен / не согласен + альтернативы + трейдоффы (не чеклист блокеров) | consult-plan- / consult-report- | | compliance | сверка реализации с исходным планом; "проверь, что реализовал план", "сверь дифф с планом" - что сделано, что пропущено, что добавлено сверх плана | medium | таблица "пункт плана -> статус (реализовано / частично / пропущено / отклонено) -> комментарий" + блок "сверх плана" | compliance-plan- / compliance-report- | | escalation | основной агент застрял (3+ провалившихся фикса, гипотезы не подтверждаются, субагент BLOCKED) - до похода к человеку | high | диагноз + root cause с доказательствами + рекомендованный подход | escalate-plan- / escalate-report- |

Общая обвязка одинакова во всех режимах: запуск через codex exec -s read-only, фиксация -C , модель - новейшая доступная (резолвится динамически, см. правило 3), pre-check и пост-сбор лимитов, блок про субагентов в плане, требование к Codex писать session id первой строкой отчета. Различаются только effort, фрейминг плана/промпта, формат ответа и имена файлов.

Когда применять

• Пользователь явно просит передать что-то в codex ("отправь codex", "пусть codex посмотрит", "второе мнение", "посоветуйся с codex").
• Нужна независимая проверка плана/диффа/архитектурного решения второй моделью.
• Нужно состязательное (adversarial) ревью (режим adversarial): не "подтверди, что ок", а "исходи из того, что дефект есть, и найди, чем решение сломается". Зовется фразами "состязательное ревью", "сломай решение", "попробуй сломать через codex".
• Нужна сверка кода с планом (режим compliance): сравнить реализованный дифф с исходным планом - что сделано, что пропущено, что отклонилось, что добавлено сверх плана. Зовется фразами "проверь, что реализовал план", "сверь дифф с планом", "compliance check". Уместно после фазы плана, до закрытия задачи.
• Основной агент застрял (режим escalation): отладка зашла в тупик, делегированный субагент вернул BLOCKED, несколько фиксов подряд не сработали - зовем Codex до того, как идти к пользователю.
• Second-opinion по умолчанию. После крупного изменения или завершенной фазы плана уместно прогнать second-opinion, не дожидаясь явной просьбы - это часть нормального workflow. Но с оглядкой: сначала pre-check лимита, и не на каждую мелочь (см. "Когда НЕ применять"). Forcing-функции через hook здесь намеренно нет - дисциплину держит этот скилл, а не блокировка.

Когда НЕ применять

• Любые изменения файлов/коммиты/деплой - codex в этом скилле всегда read-only. Фиксы по находкам применяет сам Claude в своей сессии, не Codex.
• Опечатки, пропущенные импорты, очевидные ошибки - не повод звать вторую модель.
• До того как сам провел первичное расследование - сначала разберись, потом эскалируй.
• Если задача мелкая и решается тут же без второго мнения - не плодим вызовы.

Жесткие правила

1. Всегда запускать с -s read-only. Других режимов в этом скилле нет.
2. Всегда фиксировать рабочий каталог через -C . В -C подставляй корень текущего проекта (абсолютный путь рабочего каталога), не хардкодь путь.
3. Всегда явно фиксировать модель и effort в команде:

• Модель - новейшая доступная, резолвится динамически; номер версии в скилле не хардкодим. Резолв берет эффективный дефолт самого codex (значение model из ~/.codex/config.toml, при отсутствии - из строки model · openai, которую печатает codex doctor) - сниппет в "Шаблоне вызова". Codex сам держит этот дефолт актуальным и мигрирует его при устаревании модели ([notice.model_migrations]), поэтому скилл не протухает и подхватывает новую модель без правки. Если резолв пуст (нет ни model в конфиге, ни ответа doctor) - флаг -c model автоматически не передается (собран в MODEL_FLAG, см. "Шаблон вызова"); codex возьмет собственный дефолт, а пользователя предупреждаем, какой моделью пошел запуск.
• -c model_reasoning_effort="" - по режиму: high для audit, adversarial и escalation, medium для second-opinion и compliance (доступно: minimal / low / medium / high / xhigh).
• minimal не использовать - ломается в codex-cli.
• audit, adversarial и escalation - глубокие задачи, нужна высокая глубина рассуждений (high). second-opinion намеренно легче (medium): ценность в стороннем взгляде, а не в исчерпывающей проверке. compliance тоже medium - это в основном механическая сверка пунктов плана с диффом, а не глубокий анализ.

1. План класть в docs/dev/.md (рабочая заметка, не едет на прод; имя файла - по таблице "Режимы").
2. Отчет писать в docs/dev/.md через shell-редирект, потом читать через Read.
3. Bash-таймаут поднимать до 600000ms (10 мин) - codex может думать долго, особенно на high.
4. Всегда после сессии собирать статистику лимитов аккаунта (см. блок "Статистика лимитов после сессии") - дописывать в конец .md и показывать пользователю в саммари. Без этого скилл считается выполненным некорректно: непонятно, насколько мы близко к ограничению по тарифу. Статистика по самим токенам (input/output/reasoning) намеренно не собирается - она шум, важны только проценты лимитов.
5. Всегда перед запуском codex делать pre-check короткого окна (5h / primary) лимита по последнему rollout (см. блок "Pre-check лимита перед запуском"). Если осталось `/dev/null)

[ -z "$CODEXMODEL" ] && CODEXMODEL=$(codex doctor 2>/dev/null | grep -E '^[[:space:]]*model[[:space:]]+\S+ · ' | awk '{print $2}' | head -1) MODELFLAG=(); [ -n "$CODEXMODEL" ] && MODELFLAG=(-c model="$CODEXMODEL")

Если резолв пуст (`MODEL_FLAG` пустой) - предупредить пользователя, что запуск пошел дефолтной моделью codex. Дальше подставить `"${MODEL_FLAG[@]}"` в вызов:

```bash
codex exec -s read-only \
  -C  \
  "${MODEL_FLAG[@]}" \
  -c model_reasoning_effort="" \
  "$(cat docs/dev/.md)" \
  > docs/dev/.md 2>&1

Легенда: "${MODEL_FLAG[@]}" - -c model= из резолва выше (или ничего, если не резолвилось); ` - high (audit/adversarial/escalation) или medium (second-opinion/compliance); / - имена из таблицы "Режимы"; ` - абсолютный путь корня текущего проекта, в котором сейчас идет работа.

Альтернатива со stdin (если план уже в переменной/буфере):

codex exec -s read-only \
  -C  \
  "${MODEL_FLAG[@]}" \
  -c model_reasoning_effort="" \
  - .md \
  > docs/dev/.md 2>&1

Опционально: resume существующей сессии

Для повторного раунда по той же теме (re-review после применения фиксов, уточнение мутного ответа, догрузка вопросов) можно переиспользовать сессию Codex через resume - тогда Codex не нужно заново скармливать план, файлы и фрейминг, он помнит контекст первого прохода. Экономит входной токен-бюджет и сохраняет преемственность анализа.

codex exec -s read-only -C  \
  resume "$SESSION_ID" \
  "$(cat docs/dev/.md)" \
  > docs/dev/.md 2>&1

> Порядок флагов. -s/-C/-c - опции codex exec, а resume - его подкоманда; глобальные флаги обязаны идти ДО resume. Если поставить -C/-s ПОСЛЕ resume (как аргумент подкоманды), codex падает на парсинге: error: unexpected argument '-C' found (проверено на codex v0.144.1). Первый (нессессионный) запуск - наоборот: там нет подкоманды, флаги идут сразу после codex exec.

SESSION_ID берется из шапки предыдущего отчета (Codex по нашей просьбе пишет session id: первой строкой - см. "Упаковка контекста в план"):

SESSION_ID=$(awk -F': ' '/^session id:/ {print $2; exit}' docs/dev/.md)

Особенности resume:

• -c model="..." и -c model_reasoning_effort="..." в resume игнорируются - resume наследует модель и effort исходной сессии. Это нормально для re-review того же режима; если нужна другая модель/effort - стартуй свежую сессию, не resume.
• Просьба про session id в новом плане не нужна - sessionID у продолженной сессии тот же; пост-сбор лимитов работает по тому же SESSION_ID (можно его же переиспользовать или достать из новой шапки, если Codex ее напишет).
• Pre-check лимита перед resume - такой же обязательный, как перед новым запуском: короткое окно могло быть исчерпано предыдущим раундом.
• Для каждой итерации используй отдельные имена файлов плана/отчета (-r2.md, -r2.md, дальше -r3 и т.д.), не перезаписывай предыдущие - история раундов нужна для разбора.

Опционально: фоновый запуск для долгих аудитов

codex exec синхронный и на high может думать минутами, блокируя сессию Claude. Если есть чем заняться параллельно - запускать ту же команду в фоне через run_in_background: true у Bash-тула (не через &). Сессия не блокируется, по завершении придет нотификация; тогда: собрать статистику лимитов и прочитать отчет. Это нативный способ Claude Code - никаких плагинов/обвязок не нужно. Pre-check лимита делается до фонового запуска как обычно.

Как codex выбирает модель

Порядок приоритета (от высшего к низшему):

1. -m / --model или -c model="..." в командной строке - переопределяет все.
2. [profiles.] через -p - если указан профиль.
3. ~/.codex/config.toml - глобальный дефолт.

В этом скилле мы не хардкодим номер версии, а резолвим модель динамически (см. "Шаблон вызова") и передаем через "${MODEL_FLAG[@]}" явно. Источник резолва - эффективный дефолт самого codex (model из config.toml, при отсутствии - codex doctor): codex держит его новейшим и мигрирует при устаревании модели, так что скилл идет актуальной моделью без правки. Явная передача (а не расчет на неявный дефолт в момент запуска) фиксирует, какой именно моделью пошел прогон, - это попадает в лог и саммари.

Процесс

1. Определить режим (audit / adversarial / second-opinion / compliance / escalation) - от него зависят effort, фрейминг плана, формат ответа и имена файлов (таблица "Режимы").
2. Pre-check лимита (см. блок "Pre-check лимита перед запуском"). Если короткое окно (5h / primary) показывает left .md. План самодостаточный (Codex не видит историю чата): по чеклисту "Упаковка контекста в план". Фрейминг и формат ответа - под выбранный режим.
3. Запустить codex по шаблону выше, timeout: 600000 (либо в фоне, см. "Опционально: фоновый запуск").
4. Собрать статистику лимитов (см. блок "Статистика лимитов после сессии") - дописать в конец .md.
5. Прочитать отчет через Read docs/dev/.md.
6. Разобрать находки (см. блок "Разбор находок") - верифицировать каждую, разделить на "применил / предлагаю / нужно решение". Кратко изложить пользователю (3-5 пунктов) + блок "лимиты" из двух строк (по одной на каждое окно 5h и 1w):

• : left N% (used M%), reset [D day ]H:MM hour (целые сутки + часы:минуты до конца окна);
• если по любому окну `left ".

Спросить, какие пункты брать в работу. Не браться за все молча.

1. После завершения задачи решить судьбу файлов: если задача закрыта, можно удалить ` и ` или сослаться на них из соответствующего todo.

Упаковка контекста в план

Каждый вызов Codex изолирован - план обязан быть самодостаточным. Минимум (адаптируй под режим):

• Проблема / цель - 1-2 предложения: что проверяем (audit), что пытаемся сломать (adversarial), какое решение/подход оцениваем (second-opinion), что сверяем с планом (compliance), где застряли (escalation).
• Контекст - 2-5 строк: что за фича, почему сейчас этим занимаемся.
• Ключевые файлы - конкретные пути с номерами строк (Codex видит репо, но укажи куда смотреть), не общие "посмотри в app/". Для ревью большого PR/диффа НЕ вставляй в план полный патч - дай список git diff --name-only ..HEAD плюс 2-3 хот-спота с номерами строк; Codex сам подтянет нужное через -C. Это экономит контекст ревьюера и снижает риск упереться в окно.
• Что уже пробовали (особенно для escalation) - гипотезы/фиксы и почему не сработали.
• Evidence - точные ошибки, стектрейсы, вывод тестов.
• Ожидаемый результат / формат ответа - что значит "готово"; попросить отвечать структурно по формату режима (audit -> вердикт ok/risk/blocker; adversarial -> список атак с серьезностью, "проблем нет" только с перечнем проверенного; second-opinion -> согласие + альтернативы + трейдоффы; compliance -> таблица "пункт плана -> статус -> комментарий" + блок "сверх плана"; escalation -> диагноз + root cause + подход).
• session id первой строкой - попросить Codex первой строкой отчета написать session id: (нужно для пост-сбора статистики лимитов).
• Делегирование субагентам - отдельным блоком в начале плана (шаблон ниже).

Шаблон блока про субагентов

Вставлять в начало плана дословно или близко к тексту:

## Использование субагентов

По возможности делегируй вспомогательную работу собственным субагентам на более дешевых моделях:
- поиск файлов/символов, grep по репо;
- чтение больших файлов и выборка релевантных фрагментов;
- сбор фактов (версии, конфиги, наличие/отсутствие чего-либо);
- проверка тривиальных условий ("есть ли тест на X", "используется ли функция Y").

Что НЕ делегировать дешевым моделям:
- финальные вердикты (ok / risk / blocker);
- рассуждения о безопасности, корректности логики, инвариантах;
- сводное заключение в конце отчета.

Главный критерий - качество итогового вывода. Если задача требует основной модели для сохранения качества - используй основную модель, не экономь.

Шаблоны промптов

Подставить в ` (дополнив контекстом по чеклисту "Упаковка контекста"). Во всех режимах в конце - READ-ONLY: только отчет, файлы не менять и просьба про session id` первой строкой.

Аудит

Аудит кода (read-only).

Цель: [что проверить - одна фраза]
Контекст: [2-5 строк]
Файлы: [пути с номерами строк]
Вопросы:
1. [...]
2. [...]

Формат: по каждому вопросу - вердикт ok / risk / blocker + 1-2 предложения обоснования.
Каждый risk/blocker - с точной привязкой: файл:строка + короткая цитата фрагмента,
который мотивирует находку. Находка без привязки помечается словом unverified.
READ-ONLY: только отчет, файлы не менять. Первой строкой отчета: session id: .

Состязательное (adversarial) ревью

Состязательное (adversarial) ревью (read-only).

Ты adversarial-ревьюер. Исходи из того, что это решение СОДЕРЖИТ скрытый
дефект - твоя задача найти его, а не подтвердить корректность. Не одобряй,
ломай уверенность в решении.

Что ревьюим: [код / дифф / план / спецификация - что именно]
Контекст: [2-5 строк]
Файлы: [пути с номерами строк]

Для каждого компонента ответь:
- при каких входах / состояниях / гонках / нагрузке это сломается?
- какие инварианты и предусловия предполагаются, но не гарантируются?
- где автор рассчитывал на happy path и не закрыл отказ?
- какие неявные допущения рухнут при изменении окружения / данных / масштаба?

НЕ репортить (scope exclusions):
- стиль, нейминг, форматирование, докстринги, комментарии;
- спекулятивные улучшения

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [dewil](https://github.com/dewil)
- **Source:** [dewil/claude-toolkit](https://github.com/dewil/claude-toolkit)
- **License:** MIT

Install and usage instructions live in the source repository linked above.