# Codex Audit

> Делегировать в Codex CLI (read-only) одну из пяти задач - глубокий аудит/ревью кода, состязательное (adversarial) ревью со скептической позицией ("сломай решение"), независимое второе мнение по подходу/диффу, сверка реализации с исходным планом (compliance), или диагностику когда основной агент застрял. Использовать когда пользователь просит "отправь codex на аудит", "пусть codex проверит", "сост…

- **Type:** Skill
- **Install:** `agentstack add skill-dewil-claude-toolkit-codex-audit`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [dewil](https://agentstack.voostack.com/s/dewil)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [dewil](https://github.com/dewil)
- **Source:** https://github.com/dewil/claude-toolkit/tree/main/skills/codex-audit

## Install

```sh
agentstack add skill-dewil-claude-toolkit-codex-audit
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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` - это в основном механическая сверка пунктов плана с диффом, а не глубокий анализ.
4. **План** класть в `docs/dev/.md` (рабочая заметка, не едет на прод; имя файла - по таблице "Режимы").
5. **Отчет** писать в `docs/dev/.md` через shell-редирект, потом читать через `Read`.
6. Bash-таймаут поднимать до 600000ms (10 мин) - codex может думать долго, особенно на `high`.
7. **Всегда** после сессии собирать статистику лимитов аккаунта (см. блок "Статистика лимитов после сессии") - дописывать в конец `.md` и показывать пользователю в саммари. Без этого скилл считается выполненным некорректно: непонятно, насколько мы близко к ограничению по тарифу. Статистика по самим токенам (input/output/reasoning) намеренно не собирается - она шум, важны только проценты лимитов.
8. **Всегда** перед запуском codex делать pre-check короткого окна (`5h` / `primary`) лимита по последнему rollout (см. блок "Pre-check лимита перед запуском"). Если осталось `/dev/null)
[ -z "$CODEX_MODEL" ] && CODEX_MODEL=$(codex doctor 2>/dev/null | grep -E '^[[:space:]]*model[[:space:]]+\S+ · ' | awk '{print $2}' | head -1)
MODEL_FLAG=(); [ -n "$CODEX_MODEL" ] && MODEL_FLAG=(-c model="$CODEX_MODEL")
```

Если резолв пуст (`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 (если план уже в переменной/буфере):

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

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

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

```bash
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: ` первой строкой - см. "Упаковка контекста в план"):

```bash
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 не видит историю чата): по чеклисту "Упаковка контекста в план". Фрейминг и формат ответа - под выбранный режим.
4. **Запустить codex** по шаблону выше, `timeout: 600000` (либо в фоне, см. "Опционально: фоновый запуск").
5. **Собрать статистику лимитов** (см. блок "Статистика лимитов после сессии") - дописать в конец `.md`.
6. **Прочитать отчет** через `Read docs/dev/.md`.
7. **Разобрать находки** (см. блок "Разбор находок") - верифицировать каждую, разделить на "применил / предлагаю / нужно решение". Кратко изложить пользователю (3-5 пунктов) + блок "лимиты" из двух строк (по одной на каждое окно `5h` и `1w`):
   - `: left N% (used M%), reset [D day ]H:MM hour` (целые сутки + часы:минуты до конца окна);
   - если по любому окну `left ".
   Спросить, какие пункты брать в работу. Не браться за все молча.
8. После завершения задачи решить судьбу файлов: если задача закрыта, можно удалить `` и `` или сослаться на них из соответствующего 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: ` (нужно для пост-сбора статистики лимитов).
- **Делегирование субагентам** - отдельным блоком в начале плана (шаблон ниже).

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

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

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

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

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

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

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

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

### Аудит

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

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

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

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

```text
Состязательное (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.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** yes
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-dewil-claude-toolkit-codex-audit
- Seller: https://agentstack.voostack.com/s/dewil
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.