菜单
Dispatch parallel adversarial reviews to Codex and Gemini CLIs for plans or code artifacts. Use when the AI Review Routing Policy requires two- or three-provider review — architecture-heavy, security-affecting, cross-module, or high-stakes changes.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/vamseeachanta/workspace-hub --skill multi-provider-adversarial-review命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | multi-provider-adversarial-review |
| description | Dispatch parallel adversarial reviews to Codex and Gemini CLIs for plans or code artifacts. Use when the AI Review Routing Policy requires two- or three-provider review — architecture-heavy, security-affecting, cross-module, or high-stakes changes. |
| version | 1.1.1 |
| author | Hermes Agent |
| license | MIT |
| metadata | {"hermes":{"tags":["code-review","adversarial","multi-provider","codex","gemini","quality"],"related_skills":["codex","requesting-code-review","github-issues","code-review"]}} |
Do not skip adversarial review merely because a change is "docs-only", "skill-only", "harness-only", or "workflow/report-only" when it is meaningful to the repo ecosystem. Scale the prompt depth instead:
The agent/provider that authored the change does not count as an independent adversarial reviewer. Record reviewer verdicts (APPROVE, MINOR, MAJOR), the durable artifact path committed under scripts/review/results/, the issue/PR comment URL when one exists, and the commit SHA or exact revision identifier the review evaluated. All channels that exist must be recorded; any omitted channel must be explained.
If a single provider sustains MAJOR for 3+ rounds while the other two converge on MINOR or APPROVE, surface the consensus-vs-minority decision to the user rather than auto-cycling further rounds.
The user expects adversarial review at BOTH stages — not just implementation:
Do NOT skip the plan review. Do NOT defer all review to implementation.
Write a self-contained review prompt to a temp file. The prompt must include:
# For plan review:
cat > /tmp/review-prompt.md << 'EOF'
# Adversarial Review Request: Issue #NNNN
## Your Role
You are an independent adversarial reviewer. Find gaps, risks, missing edge cases, and flawed assumptions. Do NOT rubber-stamp.
## Context
[Full background — what exists, what happened, what triggered this work]
## The Plan
[Complete plan content or issue body]
## Review Questions — Address ALL:
1. [Specific concern]
2. [Specific concern]
...
Provide verdict: APPROVE, MINOR (proceed with notes), or MAJOR (must address).
List every finding with severity (critical/high/medium/low).
EOF
# For implementation review:
# Use git diff instead of the plan
git diff main...HEAD > /tmp/diff-for-review.txt
# Then include the diff content in the review prompt
Use codex exec and gemini exec via background PTY processes:
# Codex review — prefer stdin for large/markdown-heavy prompts
cd /path/to/repo && codex exec -C /path/to/repo - < /path/to/repo/.planning/quick/review-prompt.md 2>&1 | tee /tmp/codex-review.txt
# Run with: terminal(command=..., pty=true, background=true, timeout=300)
# Gemini review (only if three-provider trigger met)
cd /path/to/repo && gemini exec "$(cat /path/to/repo/.planning/quick/review-prompt.md)" 2>&1 | tee /tmp/gemini-review.txt
# Run with: terminal(command=..., pty=true, background=true, timeout=300)
Then wait for both:
process(action="wait", session_id="<codex_id>", timeout=300)
process(action="wait", session_id="<gemini_id>", timeout=300)
Retrieve full output:
process(action="log", session_id="<codex_id>", limit=500)
process(action="log", session_id="<gemini_id>", limit=500)
Deduplicate across providers. Structure as:
## Checkpoint N: [Plan/Implementation] Adversarial Review — Codex + Gemini
### Verdicts
- **Codex**: [VERDICT] (N findings: X critical, Y high, Z medium)
- **Gemini**: [VERDICT] (N findings: ...)
### CRITICAL findings (must fix)
| # | Finding | Codex | Gemini |
|---|---------|-------|--------|
| C1 | [description] | ✓ | ✓ |
### HIGH findings (should fix before implementation)
...
### MEDIUM findings (address during implementation)
...
### LOW findings (nice to have)
...
gh issue comment NNNN --body-file /tmp/consolidated-review.md
For GTM/business-critical plan-review closeout, see references/gtm-plan-review-closeout-2026-04-29.md for a worked pattern covering live review replacement of UNAVAILABLE placeholders, owner-decision packets, numeric-claim verification, and concurrent-git closeout.
If ANY reviewer returns MAJOR at plan stage, the plan is not approval-ready and must be revised before implementation or user approval. Do not average this down because another provider returned APPROVE or MINOR. Typical pattern:
Common reviewer recommendations that recur across reviews:
When commits were pushed without review (e.g., overnight batch runs), dispatch retroactive reviews. This was proven end-to-end on 2026-04-02 (40 commits, 0 reviews → 3 MAJOR verdicts, 27 findings, 9 follow-up issues):
git log --oneline --since="..." | grep -vE '^(docs|chore|test|ci|style)' to find unreviewed feature/fix commitsterminal("cat ...") (NOT read_file which may cache). Truncate to ~20K chars per prompt. Codex sandbox CANNOT read mounted volumes.terminal("uv run python -c \"...open().write()...\"") to write prompt files to the repo dir where $(cat .planning/quick/review-X.md) works in real shell.codex exec "$(cat .planning/quick/review-X.md)" via terminal(background=true, pty=true)scripts/review/results/TIMESTAMP-retroactive-review-codex.md with tabular findingsThis catches real bugs even after the fact — the 2026-04-02 retroactive review found shell injection, race conditions, schema mismatches, and ToS compliance gaps across solver queue and GTM scanner code.
The /tmp/ trap: Hermes execute_code and write_file write to a sandbox overlay — NOT the real filesystem. So $(cat /tmp/review-prompt.md) in a terminal() call will fail with "No such file or directory" because the file only exists in the sandbox.
The workspace overlay trap: Even write_file or execute_code's write_file() targeting the workspace mount (e.g., /mnt/local-analysis/workspace-hub/.planning/quick/file.md) goes to sandbox overlay on mounted volumes.
The fix: Write prompt files via terminal() using Python:
terminal("cd /mnt/local-analysis/workspace-hub && uv run python -c \"
content = '''... your prompt ...'''
with open('.planning/quick/review-prompt.md', 'w') as f:
f.write(content)
\"")
Then dispatch: codex exec "$(cat .planning/quick/review-prompt.md)"
Alternatively, for short prompts, embed code content directly in the $(cat) heredoc — but beware shell metacharacters in code will break heredocs. The Python open().write() approach is most robust.
Codex sandbox blocks file reads — Codex exec runs in a bwrap sandbox that may block filesystem access. Pass ALL context in the prompt text itself, not via file references. The prompt must be fully self-contained.
Argument-size limits on giant inline prompts — very large review prompts can fail before the provider even starts with shell errors like Argument list too long when you do codex exec "$(cat prompt.md)" or gemini exec "$(cat prompt.md)".
.planning/quick/review-<issue>-implementation-compact-prompt.md) so the recovery path is reproducible.codex exec "$(cat prompt.md)" exits 0 but the tee/raw artifact is empty or contains no verdict, treat it as a failed dispatch, not a successful review. Retry with stdin: codex exec -C /path/to/repo - < /path/to/repo/.planning/quick/review-prompt.md 2>&1 | tee ....Gemini capacity limits — gemini-3.1-pro-preview can hit 429 MODEL_CAPACITY_EXHAUSTED errors. Gemini CLI retries automatically but may take longer. Allow extra timeout.
MAJOR, keep the issue in status:plan-review and proceed with revision work instead of waiting indefinitely for Gemini capacity to recover.docs/plans/README.mdscripts/review/results/.planning/plan-approved/*.mdgh issue view <n> --json labels,state,...
Treat missing Codex/Gemini artifacts as pending cross-review even when GitHub labels suggest a more advanced state..claude/skills/skills symlink..gemini/agents/*.md containing unsupported permissionMode keys.
Despite these warnings, both CLIs still produced valid review content. Do not treat these warnings alone as review failure. Confirm success by reading the tee'd output file and checking for a complete verdict/findings block before deciding whether to retry..planning/quick/review-<issue>-prompt.md.planning/quick/review-<issue>-codex.out and .planning/quick/review-<issue>-gemini.outscripts/review/results/YYYY-MM-DD-plan-<issue>-codex.md and ...-gemini.md
Then post a concise GitHub issue comment summarizing verdicts, shared blockers, provider-specific emphasis, and artifact paths. This keeps raw CLI noise separate from the durable review artifact and makes later governance audits much easier.429 RESOURCE_EXHAUSTED / MODEL_CAPACITY_EXHAUSTED for plan reviews. The reliable pattern is:scripts/review/results/YYYY-MM-DD-plan-<issue>-gemini.md artifact with Verdict: UNAVAILABLEClaude CLI review can fail silently or exhaust turns — claude -p may time out with an empty tee file, or exit with Error: Reached max turns before producing a usable verdict. Treat both as failed dispatches, not review evidence. Retry with a compact prompt that lists exact files, known review state, required output format, and owner-decision questions; increase --max-turns enough for the review. Save only the successful substantive output as the canonical Claude artifact.
Patched-after-MAJOR plans are not automatically approval-ready — If provider artifacts still record MAJOR but the main session patches the plan afterward, keep the local plan status conservative (draft / patched-after-review) until one of these happens: (a) a fresh provider re-review returns no blocking findings, or (b) the review summary explicitly distinguishes historical provider MAJOR artifacts from main-session inline/r3 patches and names any remaining durability blocker. Do not apply status:plan-review while the plan/review artifacts are still untracked or unpushed; first commit/push the durable plan + review artifacts, then post the GitHub summary/comment and only then transition from status:needs-plan to status:plan-review. This prevents claiming cross-review closure from stale MAJOR artifacts or non-durable local files.
GTM numeric claims need source-file calculation, not prose review — For brochure/outreach plan reviews, force at least one lane to compute headline numbers from source JSON/report files. A 2026-04-29 review caught a 108 cases caption that should have been 156 by summing the matrix; text-only reviewers had missed it. Mark each number as either verified-now or render-time recompute-required.
Concurrent background agents can make broad git status/add unusable — In active workspace-hub sessions, global git status or broad git add -A can hang behind other agents/VS Code git operations and can stage unrelated work. For review closeout, use scoped verification and staging: git diff -- <target-files>, git ls-files <target-files>, git add <target-files>, and git diff --cached --name-only. Commit only the intended review artifacts and plan patches.
When review findings produce multiple follow-up issues (common with retroactive reviews across multiple streams), create them efficiently:
gh issue create silently fails if ANY label doesn't exist. Check gh label list | grep <name> and create missing labels with gh label create "<name>" --description "..." --color "<hex>" BEFORE creating issues.terminal("uv run python -c '...open().write()...'") — avoids both sandbox overlay and shell escaping issues.execute_code — create all issues in one script, collecting URLs.gh issue comment <parent> --body-file.When the revised plan splits into phases, create child issues efficiently using execute_code with a loop rather than manual gh issue create calls. Each child issue should:
Phase 1: ... (#1668))## Parent: #NNNN as the first line of the body--body-file /dev/stdin << 'BODY' ... BODY heredoc pattern to avoid shell escaping issuesAfter creating all child issues, update the parent body to link them (replace #PENDING_N placeholders with actual issue numbers), then use gh issue edit --body-file.
The full workflow after MAJOR verdicts is:
<details> blocks)Do all issue body edits via write_file to temp path + gh issue edit --body-file. Never try to pass complex markdown through shell arguments.
Add Gemini when ANY apply:
Skip Gemini for: routine implementation, standard refactors, test additions, docs-only changes.
If a required provider cannot complete review (for example Gemini returns repeated 429 RESOURCE_EXHAUSTED / MODEL_CAPACITY_EXHAUSTED), do NOT leave the review slot missing.
Always write a canonical artifact file anyway, for example:
scripts/review/results/YYYY-MM-DD-plan-<issue>-gemini.mdscripts/review/results/YYYY-MM-DD-implementation-<issue>-gemini.mdThat placeholder artifact should record:
UNAVAILABLE or equivalent explicit statusretry later, proceed with reduced-provider review, or block approval)Why this matters:
Shell escaping — Long prompts with backticks, single quotes, and parentheses break gh issue comment --body '...'. Always use --body-file instead. Same for gh issue edit --body — always use --body-file.
Prompt injection via $(cat) — Using $(cat /tmp/file.md) to inject into CLI args works but the file content must not contain unescaped shell metacharacters that could break the outer command. The temp-file approach is robust.
Review timing — User expects review at BOTH plan and implementation stages. Do not skip plan review or defer everything to code review. This was explicitly corrected during first use.
Verdict thresholds:
Don't fix the issue body inline with shell — Complex issue bodies with code blocks, backticks, parentheses, and single quotes will break shell heredocs. Always write_file to a temp path, then gh issue edit --body-file /tmp/file.md.
Gemini exec syntax — Use gemini exec "prompt" not gemini "prompt". Same pattern as codex exec "prompt".
Gemini startup warnings are often non-fatal — Gemini CLI may emit agent-loading validation warnings (for example around .gemini/agents/*.md keys such as permissionMode) or a failed tool lookup before the actual review body. Do not discard the run automatically; inspect the output after the warnings because the substantive review often still completes successfully.
Codex output is duplicated — Codex exec prints the full review twice in the terminal output (once during streaming, once as final summary). When parsing with process(action="log"), the review content appears doubled. Extract only the first occurrence or use the tee'd file.
Sandbox filesystem mismatch — On machines with mounted volumes (e.g., /mnt/local-analysis/), the write_file and patch tools may write to a sandbox overlay instead of the real mount. Files appear written but don't land on disk. Use execute_code with from hermes_tools import write_file for mounted filesystems. ALWAYS verify with terminal("wc -l /path") after writing. This caused a broken commit where old file content was committed instead of new implementation — the entire Checkpoint 2 review then reviewed stale code, producing false MAJOR findings.
Don't prematurely revert "drift" — If an AI tool update intentionally modifies files (e.g., Hermes rewrites its shebang to point to the venv Python), reverting that change will break the tool. Always understand WHY a file was modified before reverting. This was a real incident: reverting the Hermes shebang from venv path back to #!/usr/bin/env python3 caused ModuleNotFoundError because system Python lacked venv dependencies.
Stale file content in review prompts — When preparing Checkpoint 2 (implementation review), read_file may serve cached pre-commit content if the file was read earlier in the session. The reviewer then reviews the OLD code, not the new implementation, producing false MAJOR findings ("only 4 tools" when there are actually 7). Always read files fresh for review prompts — use terminal("cat path/to/file") or git show HEAD:path/to/file to get the actual committed content. Verify with grep -c 'key_function_name' before sending to reviewers.
Reviewers catch real schema/wiring bugs — Even when findings about the code itself are based on stale content, reviewers often catch legitimate integration issues (e.g., "the scheduler doesn't consume the new schedule_by_machine field"). These downstream wiring bugs are some of the highest-value review findings. Always check whether consumer scripts need updating when you add new config schema fields.
git commit captures staged content, not working tree — If you git add files, then overwrite them with write_file (to sandbox), git commit captures the OLD staged content. The fix: write via execute_code to the real filesystem, THEN git add, THEN git commit. If you discover this after committing, git commit --amend after re-adding the correct files.
execute_code /tmp/ is NOT real /tmp/ — Files written by execute_code (including its write_file() and terminal()) to /tmp/ exist only in the sandbox overlay. A subsequent terminal() call (which runs in the real shell) cannot see them. This caused the first Codex dispatch attempt to fail with "No such file or directory" when $(cat /tmp/review-prompt.md) was used. The fix: write review prompt files to the workspace directory via terminal("uv run python -c '...'") so both Hermes tools and real shell commands can see them. Clean up afterward (rm .planning/quick/review-*.md).
Full end-to-end after implementation — After implementing and getting adversarial review, the next logical step is always: (a) verify the wiring works (run the new script, regenerate crontab, etc.), (b) create follow-up issues for deployment to other machines and for items deferred during review (supply chain hardening, simulated breakage testing, active push notifications), (c) document everything in a closing comment on the parent issue.
Do NOT write long review prompts via shell heredoc inside terminal() when they contain markdown code spans/fences — A real failure mode on 2026-04-12: writing a review prompt with bash -lc 'cat <<'"'"'EOF' ... EOF' caused shell interpretation to break and lines from the embedded markdown/code content were executed as commands (scripts/cron/weekly-hermes-parity-review.sh, YAML lines, benchmark scripts), producing side effects and a timeout. For long self-contained prompts on mounted filesystems, prefer execute_code/write_file() to create the prompt file, then verify with wc -l path/to/prompt.md before dispatching Codex/Gemini. If you must use shell, avoid embedding backticks/code fences and verify the file content before launching reviewers.
Mixed verdict synthesis rule — If Codex and Gemini disagree (for example APPROVE from one and MAJOR from the other), treat the plan as NOT approval-ready until the MAJOR findings are addressed. A single MAJOR is sufficient to block plan approval under adversarial review discipline.
Plan-review backlog triage must not rely on status:plan-review labels alone — In live use on 2026-04-14, there were zero open issues labeled status:plan-review, yet several open issues still lacked Codex/Gemini plan-review artifacts or had drift between plan file status, docs/plans/README.md, .planning/plan-approved/*.md, GitHub labels, and actual review artifacts. For plan cross-review sweeps, inspect ALL of these together: