ddmitry/adversarial-review
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: translate SKILL.md to English, add permissions guide

Browse Source 
- Why:
  - English makes the skill accessible to a wider audience
  - Permission prompts on every git/codex call hurt UX
- What:
  - Translated all SKILL.md instructions and rules to English
  - Added recommended permissions section to README
  - Removed literal ## from output_format to avoid Claude Code
    security warning about # in quoted arguments
  - Removed overly broad Bash(codex *) permission rule
  - Added explicit note about codex exec scope limitations
- Verify:
  - /adversarial-review produces structured output with markdown headers
  - No "Newline followed by #" security warning on codex exec

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
ddadmin
2026-04-03 20:06:22 +03:00
co-authored by Claude Opus 4.6
parent 515820abed
commit 649256517e
2 changed files with 186 additions and 158 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+30
View File
@@ -83,6 +83,36 @@ ln -s "$(pwd)/adversarial-review" ~/.agents/skills/adversarial-review
After symlinking, the skill is available as `/adversarial-review` in Claude Code. After symlinking, the skill is available as `/adversarial-review` in Claude Code.
### Recommended permissions
The skill runs git, codex, and `/tmp` write commands that will trigger
permission prompts. To avoid repeated confirmations, add these to your
`.claude/settings.local.json`:
```json
{
"permissions": {
"allow": [
"Bash(git diff*)",
"Bash(git status*)",
"Bash(git symbolic-ref*)",
"Bash(git rev-parse*)",
"Bash(timeout 600 codex exec *)",
"Bash(rm -f /tmp/claude-plan-*)",
"Bash(rm -f /tmp/codex-review-*)",
"Write(/tmp/claude-plan-*)",
"Write(/tmp/codex-review-*)"
]
}
}
```
**Note:** The `codex exec` rule allows any `codex exec` invocation wrapped
in `timeout 600`. The skill only uses read-only mode (`-s read-only`), but
Claude Code's permission patterns are prefix-based and cannot enforce flag
constraints. If you prefer tighter control, omit the `codex exec` rule and
approve each review invocation manually.
## Usage ## Usage
``` ```
SKILL.md
+156 -158
View File
@@ -1,113 +1,113 @@
--- ---
name: adversarial-review name: adversarial-review
description: Adversarial AI code/plan review. Codex ревьюит, Claude правит, итеративный цикл до одобрения. Автодетект режима plan/code/code-vs-plan. description: Adversarial AI code/plan review. Codex reviews, Claude fixes, iterative loop until approved. Auto-detects plan/code/code-vs-plan mode.
user_invocable: true user_invocable: true
--- ---
# Adversarial Code Review # Adversarial Code Review
Отправляет текущую работу на adversarial-ревью через внешнюю AI-модель (по умолчанию — OpenAI Codex). Автоматически определяет, что ревьюить: **план** или **код**. Claude правит по замечаниям ревьюера и переотправляет до одобрения. Максимум 5 раундов. Sends current work for adversarial review through an external AI model (OpenAI Codex by default). Auto-detects what to review: **plan** or **code**. Claude fixes issues based on reviewer feedback and resubmits until approved. Maximum 5 rounds.
--- ---
## Когда вызывать ## When to invoke
- `/adversarial-review` — автодетект что ревьюить - `/adversarial-review` — auto-detect what to review
- `/adversarial-review plan` — принудительно ревью плана - `/adversarial-review plan` — force plan review
- `/adversarial-review code` — принудительно ревью кода - `/adversarial-review code` — force code review
- `/adversarial-review <путь-к-файлу>` — ревью конкретного файла (аргумент содержит `/` или `.`) - `/adversarial-review <file-path>` — review a specific file (argument contains `/` or `.`)
- Переопределение reasoning: `/adversarial-review xhigh` или `/adversarial-review low` (одно из: `none`, `low`, `medium`, `high`, `xhigh`) - Override reasoning: `/adversarial-review xhigh` or `/adversarial-review low` (one of: `none`, `low`, `medium`, `high`, `xhigh`)
- Переопределение модели: `/adversarial-review model:gpt-5.3-codex` (аргумент с префиксом `model:`) - Override model: `/adversarial-review model:gpt-5.3-codex` (argument with `model:` prefix)
## Инструкции ## Instructions
> **Плейсхолдеры:** `${REVIEW_ID}`, `${CODEX_SESSION_ID}` и `${BASE_BRANCH}` в шагах ниже — это шаблонные плейсхолдеры, НЕ shell-переменные. Подставляй литеральные значения напрямую в каждый tool call. > **Placeholders:** `${REVIEW_ID}`, `${CODEX_SESSION_ID}` and `${BASE_BRANCH}` in the steps below are template placeholders, NOT shell variables. Substitute literal values directly into each tool call.
### Шаг 1: Определить режим ревью ### Step 1: Determine review mode
Определи, что ревьюить. Проверяй в порядке приоритета: Determine what to review. Check in priority order:
**1. Явный аргумент** (`plan`, `code`, путь к файлу) → использовать его. **1. Explicit argument** (`plan`, `code`, file path) → use it.
- Для `plan` → пропустить все git-проверки, перейти к шагу 2 (только REVIEW_ID). - For `plan` → skip all git checks, proceed to step 2 (REVIEW_ID only).
**2. Claude Code Plan Mode** — если в контексте есть системное сообщение "Plan mode is active" → режим = `plan`, пропустить git. В Plan Mode код не редактируется, поэтому code/code-vs-plan невозможны. **2. Claude Code Plan Mode** — if context contains the system message "Plan mode is active" → mode = `plan`, skip git. In Plan Mode code is not edited, so code/code-vs-plan are impossible.
**3. Автодетект** (без явного аргумента, вне Plan Mode): **3. Auto-detect** (no explicit argument, not in Plan Mode):
1. Проверь наличие изменений кода (любой непустой — значит есть): 1. Check for code changes (any non-empty output means changes exist):
- `git diff --name-only` — unstaged - `git diff --name-only` — unstaged
- `git diff --cached --name-only` — staged - `git diff --cached --name-only` — staged
- `git diff --name-only ${BASE_BRANCH}...HEAD` — коммиты ветки - `git diff --name-only ${BASE_BRANCH}...HEAD` — branch commits
2. Проверь, есть ли план в текущем контексте разговора (из plan mode, задач или обсуждения). 2. Check if a plan exists in the current conversation context (from plan mode, tasks, or discussion).
| Изменения кода? | План в контексте? | Режим | | Code changes? | Plan in context? | Mode |
|----------------|-------------------|-------| |--------------|-----------------|------|
| Нет | Да | **plan** — ревью плана | | No | Yes | **plan** — review the plan |
| Да | Да | **code-vs-plan** — ревью реализации против плана | | Yes | Yes | **code-vs-plan** — review implementation against plan |
| Да | Нет | **code** — ревью изменений кода | | Yes | No | **code** — review code changes |
| Нет | Нет | Спросить пользователя, что ревьюить | | No | No | Ask the user what to review |
### Шаг 2: Сгенерировать Session ID и определить base branch ### Step 2: Generate Session ID and determine base branch
Сгенерируй уникальный `REVIEW_ID` самостоятельно, формат: `{unix_timestamp}-{случайное_4значное_число}`. Generate a unique `REVIEW_ID` yourself, format: `{unix_timestamp}-{random_4digit_number}`.
Пример: `1711872000-4821`. **НЕ используй bash** — подставляй значение напрямую в команды следующих шагов. Example: `1711872000-4821`. **Do NOT use bash** — substitute the value directly into commands in the following steps.
**Определение base branch (только для режимов `code` и `code-vs-plan`):** **Determining base branch (only for `code` and `code-vs-plan` modes):**
Для режима `plan` — пропустить определение base branch, перейти к шагу 3. For `plan` mode — skip base branch detection, proceed to step 3.
Для остальных режимов определи base branch репозитория: For other modes, determine the repository's base branch:
```bash ```bash
git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||' git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||'
``` ```
Если команда вернула пустой результат (remote HEAD не настроен), используй fallback: If the command returns empty (remote HEAD not configured), use fallback:
```bash ```bash
git rev-parse --verify main 2>/dev/null && echo main || echo master git rev-parse --verify main 2>/dev/null && echo main || echo master
``` ```
Сохрани результат как `BASE_BRANCH` — используется в `git diff ${BASE_BRANCH}...HEAD` далее. Save the result as `BASE_BRANCH` — used in `git diff ${BASE_BRANCH}...HEAD` below.
### Шаг 3: Подготовить материал для ревью ### Step 3: Prepare review material
**Ревью плана:** **Plan review:**
- Если план уже существует как файл (в `project/`, plan file от Plan Mode, memory или где-то в репо) — использовать путь напрямую. НЕ копировать. В Claude Code Plan Mode план всегда является файлом. - If the plan already exists as a file (in `project/`, plan file from Plan Mode, memory, or somewhere in the repo) — use the path directly. Do NOT copy. In Claude Code Plan Mode the plan is always a file.
- Если план только в контексте разговора (вне Plan Mode) — записать через **Write tool** в `/tmp/claude-plan-${REVIEW_ID}.md`. - If the plan is only in the conversation context (outside Plan Mode) — write via **Write tool** to `/tmp/claude-plan-${REVIEW_ID}.md`.
- **Обязательно вывести путь к файлу плана пользователю**, чтобы он мог открыть его в IDE: - **Always print the plan file path for the user** so they can open it in their IDE:
`📄 План для ревью: <путь-к-файлу>` `Plan for review: <file-path>`
**Ревью кода:** **Code review:**
Собери список изменённых файлов: Collect the list of changed files:
1. `git diff --name-only` — unstaged changes 1. `git diff --name-only` — unstaged changes
2. `git diff --cached --name-only` — staged changes 2. `git diff --cached --name-only` — staged changes
Объедини unstaged + staged (уникальные пути). Если оба пусты: Merge unstaged + staged (unique paths). If both are empty:
3. `git diff --name-only ${BASE_BRANCH}...HEAD` — коммиты ветки (fallback) 3. `git diff --name-only ${BASE_BRANCH}...HEAD` — branch commits (fallback)
Branch берётся ТОЛЬКО когда нет локальных изменений — иначе контекст раздувается. Branch diff is used ONLY when there are no local changes — otherwise context bloats.
Для branch в промпте указывай команду `git diff ${BASE_BRANCH}...HEAD` (полный diff). For branch diff, include the command `git diff ${BASE_BRANCH}...HEAD` (full diff) in the prompt.
Ревьюер имеет доступ к репо и сам прочитает полный diff и файлы. The reviewer has access to the repo and will read full diffs and files on its own.
В промпт (шаг 4) передай список файлов и какие git diff команды запускать. In the prompt (step 4), pass the file list and which git diff commands to run.
**Много файлов (> 50):** если объединённый список превышает 50 путей, **Many files (> 50):** if the combined list exceeds 50 paths,
передай в промпт только git-команды без списка файлов — ревьюер разберётся сам. pass only git commands without the file list — the reviewer will figure it out.
Если все источники пусты — нет изменений для ревью, сообщи пользователю. If all sources are empty — no changes to review, inform the user.
**Ревью кода против плана:** подготовить путь к плану И собрать список изменённых файлов (как выше). **Code-vs-plan review:** prepare the plan path AND collect the list of changed files (as above).
### Шаг 4: Сформировать промпт и запустить первый раунд ### Step 4: Build the prompt and launch the first round
Сформируй промпт в зависимости от режима. Все промпты используют adversarial stance. Build the prompt depending on the mode. All prompts use the adversarial stance.
**Промпт для ревью плана:** **Prompt for plan review:**
``` ```
<role> <role>
@@ -154,12 +154,12 @@ If the plan is solid, say so clearly — false positives erode trust.
</calibration> </calibration>
<output_format> <output_format>
## Summary Use markdown headers for sections: Summary, Findings, Verdict.
One paragraph: what this plan does and your overall assessment.
## Findings Summary: one paragraph — what this plan does and your overall assessment.
For each finding:
### [severity: critical|high|medium] Finding title Findings: for each finding, use a sub-header with [severity: critical|high|medium] and title.
Include these fields per finding:
- **Section:** which part of the plan - **Section:** which part of the plan
- **What can go wrong:** ... - **What can go wrong:** ...
- **Why vulnerable:** ... - **Why vulnerable:** ...
@@ -168,15 +168,14 @@ For each finding:
If no findings: "No actionable findings." If no findings: "No actionable findings."
## Verdict Verdict rules: approve if no findings or all low severity; revise if any high/critical.
Rules: approve if no findings or all low severity; revise if any high/critical.
Choose exactly one. The LAST line of your response must be one of: Choose exactly one. The LAST line of your response must be one of:
VERDICT: APPROVED VERDICT: APPROVED
VERDICT: REVISE VERDICT: REVISE
</output_format> </output_format>
``` ```
**Промпт для ревью кода (<= 50 файлов):** **Prompt for code review (<= 50 files):**
``` ```
<role> <role>
@@ -194,7 +193,7 @@ If something only works on the happy path, treat that as a real weakness.
<task> <task>
Review the code changes in this repo. Changed files: Review the code changes in this repo. Changed files:
<список файлов из --name-only> <file list from --name-only>
Changes include: <unstaged changes / staged changes / unstaged + staged changes / branch changes vs ${BASE_BRANCH}>. Changes include: <unstaged changes / staged changes / unstaged + staged changes / branch changes vs ${BASE_BRANCH}>.
Run <git diff commands> to see the full diffs. Run <git diff commands> to see the full diffs.
@@ -232,12 +231,12 @@ If the change is solid, say so clearly — false positives erode trust.
</calibration> </calibration>
<output_format> <output_format>
## Summary Use markdown headers for sections: Summary, Findings, Verdict.
One paragraph: what this change does and your overall assessment.
## Findings Summary: one paragraph — what this change does and your overall assessment.
For each finding:
### [severity: critical|high|medium] Finding title Findings: for each finding, use a sub-header with [severity: critical|high|medium] and title.
Include these fields per finding:
- **File:** path/to/file.ext lines N-M - **File:** path/to/file.ext lines N-M
- **What can go wrong:** ... - **What can go wrong:** ...
- **Why vulnerable:** ... - **Why vulnerable:** ...
@@ -246,17 +245,16 @@ For each finding:
If no findings: "No actionable findings." If no findings: "No actionable findings."
## Verdict Verdict rules: approve if no findings or all low severity; revise if any high/critical.
Rules: approve if no findings or all low severity; revise if any high/critical.
Choose exactly one. The LAST line of your response must be one of: Choose exactly one. The LAST line of your response must be one of:
VERDICT: APPROVED VERDICT: APPROVED
VERDICT: REVISE VERDICT: REVISE
</output_format> </output_format>
``` ```
**Промпт для ревью кода (> 50 файлов):** **Prompt for code review (> 50 files):**
Тот же промпт, что выше, но секция `<task>` без списка файлов: Same prompt as above, but the `<task>` section without the file list:
``` ```
<task> <task>
Review the code changes in this repo. Review the code changes in this repo.
@@ -265,35 +263,35 @@ Run <git diff commands> to see changed files and full diffs.
</task> </task>
``` ```
**Промпт для ревью кода против плана:** **Prompt for code-vs-plan review:**
Тот же промпт для ревью кода, но секция `<task>` дополняется: Same prompt as code review, but the `<task>` section is extended:
``` ```
<task> <task>
Review the code changes in this repo against the implementation plan in <plan-path>. Review the code changes in this repo against the implementation plan in <plan-path>.
Changed files: Changed files:
<список файлов или пусто если > 50> <file list or empty if > 50>
Changes include: <тип>. Changes include: <type>.
Run <git diff commands> to see the full diffs. Run <git diff commands> to see the full diffs.
</task> </task>
``` ```
И в `<attack_surface>` добавляются пункты: And the following items are added to `<attack_surface>`:
``` ```
- Completeness: does the implementation cover all plan steps? - Completeness: does the implementation cover all plan steps?
- Deviations: where does the code differ from the plan? Are deviations justified? - Deviations: where does the code differ from the plan? Are deviations justified?
- Missing: what from the plan is not yet implemented? - Missing: what from the plan is not yet implemented?
``` ```
**Запуск Codex — шаблон команды:** **Launching Codex — command template:**
Флаги: Flags:
- `-m gpt-5.4` — модель (переопределяется аргументом `model:...`) - `-m gpt-5.4` — model (overridden by `model:...` argument)
- `-c model_reasoning_effort=high` — глубина рассуждения (переопределяется аргументом `xhigh`, `low` и т.д.) - `-c model_reasoning_effort=high` — reasoning depth (overridden by `xhigh`, `low`, etc.)
- `-s read-only` — ревьюер только читает, не пишет - `-s read-only` — reviewer only reads, does not write
- `-o /tmp/codex-review-${REVIEW_ID}.md` — файл для записи ответа - `-o /tmp/codex-review-${REVIEW_ID}.md` — file for capturing output
```bash ```bash
timeout 600 codex exec \ timeout 600 codex exec \
@@ -301,71 +299,71 @@ timeout 600 codex exec \
-c model_reasoning_effort=high \ -c model_reasoning_effort=high \
-s read-only \ -s read-only \
-o /tmp/codex-review-${REVIEW_ID}.md \ -o /tmp/codex-review-${REVIEW_ID}.md \
"ПРОМПТ" "PROMPT"
``` ```
**Важно:** **Important:**
- Всегда оборачивай `codex exec` в `timeout 600` (10 минут). Если Codex зависнет — команда завершится с кодом 124. - Always wrap `codex exec` in `timeout 600` (10 minutes). If Codex hangs — the command exits with code 124.
- Используй параметр `timeout: 620000` в Bash tool для запаса. - Use `timeout: 620000` parameter in Bash tool for headroom.
- Команда **синхронная**: когда она вернулась, файл `-o` уже готов. **НЕ** используй poll-loop (`while/sleep`). - The command is **synchronous**: when it returns, the `-o` file is ready. Do **NOT** use a poll-loop (`while/sleep`).
- Если exit code = 124 (таймаут) — сообщи пользователю и предложи повторить. - If exit code = 124 (timeout) — inform the user and offer to retry.
**После запуска:** найди в выводе строку `session id: <uuid>` и сохрани значение как `CODEX_SESSION_ID` — оно нужно для `resume` в последующих раундах. **After launch:** find the `session id: <uuid>` line in the output and save the value as `CODEX_SESSION_ID` — needed for `resume` in subsequent rounds.
**Примечания:** **Notes:**
- Модель по умолчанию: `gpt-5.4` с `model_reasoning_effort=high`. Пользователь может переопределить через аргументы. - Default model: `gpt-5.4` with `model_reasoning_effort=high`. User can override via arguments.
- Всегда `-s read-only` — ревьюер не должен писать файлы. - Always `-s read-only` — reviewer must not write files.
- `-o` для захвата вывода в файл. **НЕ** запускай в background — команда сама вернёт управление. - `-o` captures output to file. Do **NOT** run in background — the command returns control on its own.
### Шаг 5: Прочитать ревью и проверить вердикт ### Step 5: Read the review and check the verdict
1. Прочитать `/tmp/codex-review-${REVIEW_ID}.md` 1. Read `/tmp/codex-review-${REVIEW_ID}.md`
2. Показать пользователю **дословно** (verbatim) — не перефразировать findings ревьюера: 2. Show the user **verbatim** — do not rephrase the reviewer's findings:
``` ```
## Adversarial Review — Раунд N (режим: <plan|code|code-vs-plan>, модель: gpt-5.4) ## Adversarial Review — Round N (mode: <plan|code|code-vs-plan>, model: gpt-5.4)
[Отзыв ревьюера — дословно] [Reviewer's response — verbatim]
``` ```
3. Проверить вердикт: 3. Check the verdict:
- **VERDICT: APPROVED** → перейти к Шагу 8 (Готово) - **VERDICT: APPROVED** → proceed to Step 8 (Done)
- **VERDICT: REVISE** → перейти к Шагу 6 (Правки) - **VERDICT: REVISE** → proceed to Step 6 (Fixes)
- Нет явного вердикта → считать parse failure, запустить resume/fallback с просьбой дать чёткий вердикт - No clear verdict → treat as parse failure, run resume/fallback requesting a clear verdict
- Достигнут максимум (5 раундов) → перейти к Шагу 8 с пометкой - Maximum reached (5 rounds) → proceed to Step 8 with a note
### Шаг 6: Внести правки ### Step 6: Apply fixes
По замечаниям ревьюера: Based on the reviewer's findings:
**Для ревью плана:** исправить план — адресовать каждое замечание. Обновить файл плана (или temp-файл). Показать пользователю: **For plan review:** fix the plan — address each finding. Update the plan file (or temp file). Show the user:
``` ```
### Правки (Раунд N) ### Fixes (Round N)
- [Что изменено и почему, один пункт на замечание] - [What was changed and why, one item per finding]
``` ```
**Для ревью кода:** исправить код напрямую — редактировать файлы, запустить тесты если применимо. Показать пользователю: **For code review:** fix the code directly — edit files, run tests if applicable. Show the user:
``` ```
### Исправления (Раунд N) ### Fixes (Round N)
- [Что исправлено и почему, один пункт на замечание] - [What was fixed and why, one item per finding]
``` ```
**Пропустить** правку, если она противоречит явным требованиям пользователя — отметить это для пользователя. **Skip** a fix if it contradicts the user's explicit requirements — note this for the user.
### Шаг 7: Переотправить в Codex (Раунды 2-5) ### Step 7: Resubmit to Codex (Rounds 2-5)
**Resume — основной путь.** Экономит токены и сохраняет контекст сессии. Свежий `codex exec` без resume — **аварийный fallback**, расходует значительно больше токенов. Использовать только при ошибке resume. **Resume is the primary path.** Saves tokens and preserves session context. A fresh `codex exec` without resume is an **emergency fallback** that costs significantly more tokens. Use only if resume fails.
1. Запусти resume с подавлением stderr (`2>/dev/null`): 1. Run resume with stderr suppressed (`2>/dev/null`):
```bash ```bash
timeout 600 codex exec resume ${CODEX_SESSION_ID} \ timeout 600 codex exec resume ${CODEX_SESSION_ID} \
"I've revised based on your feedback. "I've revised based on your feedback.
Here's what I changed: Here's what I changed:
[Список правок] [List of fixes]
Re-review with the same adversarial stance. Focus on: Re-review with the same adversarial stance. Focus on:
1. Whether my fixes actually resolve the reported issues 1. Whether my fixes actually resolve the reported issues
@@ -374,74 +372,74 @@ Re-review with the same adversarial stance. Focus on:
End with VERDICT: APPROVED or VERDICT: REVISE" 2>/dev/null End with VERDICT: APPROVED or VERDICT: REVISE" 2>/dev/null
``` ```
Используй `timeout: 620000` в параметрах Bash tool. Use `timeout: 620000` in Bash tool parameters.
**Почему `2>/dev/null`:** `codex exec` по дизайну разделяет потоки — progress/metadata → stderr, финальный ответ модели → stdout. Подавление stderr даёт чистый вывод без CLI-шума. Результат Bash tool = только ревью. **Why `2>/dev/null`:** `codex exec` by design separates streams — progress/metadata → stderr, final model response → stdout. Suppressing stderr gives clean output without CLI noise. The Bash tool result = review only.
2. Проверь результат по exit code: 2. Check the result by exit code:
- **exit 0** — успех. stdout содержит чистое ревью. Показать пользователю напрямую (Write в файл и Read **не нужны**). Проверить VERDICT: последняя непустая строка stdout = `VERDICT: APPROVED` или `VERDICT: REVISE`. Если вердикт отсутствует → вывод мог быть обрезан, перейти к Fallback. Далее применить обработку вердикта из Шага 5 (APPROVED → Шаг 8, REVISE → Шаг 6). - **exit 0** — success. stdout contains clean review. Show to user directly (Write to file and Read are **not needed**). Check VERDICT: the last non-empty line of stdout = `VERDICT: APPROVED` or `VERDICT: REVISE`. If verdict is missing → output may have been truncated, proceed to Fallback. Then apply verdict handling from Step 5 (APPROVED → Step 8, REVISE → Step 6).
- **exit 124** — таймаут. Сообщи пользователю: "Ревьюер не ответил за 10 минут" и предложи повторить. - **exit 124** — timeout. Tell the user: "Reviewer did not respond within 10 minutes" and offer to retry.
- **другой exit code** — сообщи пользователю: "Resume не удался (exit code N)". Перейди к Fallback. Диагностика без stderr недоступна — не пытайся парсить stdout как ошибку. - **other exit code** — tell the user: "Resume failed (exit code N)". Proceed to Fallback. Diagnostics without stderr are unavailable — do not try to parse stdout as an error.
**Fallback** — если `resume` не сработал (сессия истекла, session ID не захвачен, ошибка): **Fallback** — if `resume` did not work (session expired, session ID not captured, error):
1. Собрать список изменённых файлов (аналогично Шагу 3). 1. Collect the list of changed files (same as Step 3).
2. Запустить свежий `codex exec -o` с описанием предыдущих раундов в промпте. 2. Launch a fresh `codex exec -o` with a description of previous rounds in the prompt.
Вернуться к **Шагу 5**. Return to **Step 5**.
### Шаг 8: Итоговый результат ### Step 8: Final result
**Одобрено:** **Approved:**
``` ```
## Adversarial Review — Итог (режим: <режим>, модель: gpt-5.4) ## Adversarial Review — Summary (mode: <mode>, model: gpt-5.4)
**Статус:** ✅ Одобрено после N раунд(ов) **Status:** Approved after N round(s)
[Итоговый отзыв] [Final review]
--- ---
**Проверено и одобрено ревьюером. Ожидает вашего решения.** **Reviewed and approved by the reviewer. Awaiting your decision.**
``` ```
**Достигнут максимум раундов:** **Maximum rounds reached:**
``` ```
## Adversarial Review — Итог (режим: <режим>, модель: gpt-5.4) ## Adversarial Review — Summary (mode: <mode>, model: gpt-5.4)
**Статус:** ⚠️ Достигнут максимум (5 раундов) — не полностью одобрено **Status:** Maximum reached (5 rounds) — not fully approved
**Оставшиеся замечания:** **Remaining findings:**
[Нерешённые вопросы] [Unresolved issues]
--- ---
**У ревьюера остались замечания. Просмотрите их и решите, как действовать дальше.** **The reviewer still has findings. Please review them and decide how to proceed.**
``` ```
### Шаг 9: Очистка ### Step 9: Cleanup
**В Claude Code Plan Mode:** пропустить любой cleanup (включая deferred). rm вызовет permission prompt. Файлы подчистятся при следующем вызове вне Plan Mode. **In Claude Code Plan Mode:** skip all cleanup (including deferred). rm will trigger a permission prompt. Files will be cleaned up on the next invocation outside Plan Mode.
**Вне Plan Mode:** **Outside Plan Mode:**
```bash ```bash
rm -f /tmp/claude-plan-${REVIEW_ID}.md /tmp/codex-review-${REVIEW_ID}.md rm -f /tmp/claude-plan-${REVIEW_ID}.md /tmp/codex-review-${REVIEW_ID}.md
``` ```
Если пользователь отклонил rm — продолжить без ошибки. If the user declined rm — continue without error.
НЕ удалять файлы планов, которые существовали до ревью (только temp-файлы, созданные этим скиллом). Старые temp-файлы от предыдущих сессий безвредны в /tmp и очистятся ОС при перезагрузке. Do NOT delete plan files that existed before the review (only temp files created by this skill). Old temp files from previous sessions are harmless in /tmp and will be cleaned up by the OS on reboot.
## Правила ## Rules
- Claude **активно правит** по замечаниям ревьюера — это НЕ просто передача сообщений - Claude **actively fixes** issues based on reviewer feedback — this is NOT just message forwarding
- Findings ревьюера показываются **дословно** (verbatim) — не перефразировать, не сокращать - Reviewer findings are shown **verbatim** — do not rephrase or shorten
- Автодетект режима ревью по контексту; аргументы пользователя имеют приоритет - Auto-detect review mode from context; user arguments take priority
- При явном аргументе `plan` или в Claude Code Plan Mode: пропускать git-проверки и определение base branch - With explicit `plan` argument or in Claude Code Plan Mode: skip git checks and base branch detection
- Resume — основной путь для повторных раундов. Свежий exec — аварийный fallback (дорогой по токенам) - Resume is the primary path for subsequent rounds. Fresh exec is an emergency fallback (expensive in tokens)
- Cleanup — best-effort: в Plan Mode пропускать, при отказе продолжать без ошибки - Cleanup is best-effort: skip in Plan Mode, continue without error if declined
- Предпочитать существующие файлы, не создавать лишние копии - Prefer existing files, do not create unnecessary copies
- Всегда read-only sandbox — ревьюер никогда не пишет файлы - Always read-only sandbox — reviewer never writes files
- Максимум 5 раундов для защиты от бесконечных циклов - Maximum 5 rounds to protect against infinite loops
- Показывать пользователю отзывы и правки каждого раунда - Show the user reviews and fixes for each round
- Если Codex CLI не установлен или упал — сообщить пользователю: `npm install -g @openai/codex` - If Codex CLI is not installed or crashed — tell the user: `npm install -g @openai/codex`
- Если правка противоречит явным требованиям пользователя — пропустить и объяснить почему - If a fix contradicts the user's explicit requirements — skip and explain why