我之前的工作流是opus写计划，sonnet执行，最近一段时间就琢磨把opus写的计划或者其他文档拿给codex先review。

刚开始是开两个 tmux pane，左边codex，右边claude，拿着claude 的计划给 codex， codex 审完，claude 改，claude 改完codex审……，而我在中间充当提示词的搬运工，主打一个复制和粘贴。

后来觉得实在太累了，想着既然codex有cli模式，不如让claude自己调用他，于是乎让claude给我写了这个 skill，再经过多轮迭代和踩坑，最后有了目前我一直在用的版本。

几个关键点：

• codex 一定要开 --yolo，这个就不解释了
• 一定要让 codex 在之前的会话进行 review，而不是重新开一个新的会话，不然你会发现 codex 每轮审查都能发现10个新问题，还不带重样的
• 还有个就是需要被审查的文档和提示词是用 stdin pipe 传进 codex的，因为我发现直接把prompt 通过命令行参数传入，由于codex的沙盒机制，会让codex一直处于等待stdin的状态而卡住

下面是具体的skill，使用方法很简单，claude 写完文档之后，直接调用 /devil-review ，claude 会在自动跑codex，拿到建议后修改，修改完了继续让codex审查……，循环直到codex 满意为止（设置默认最大循环次数10次），一般4-5次修改就会结束。

--- name: devil-review description: Run any markdown document or code change (diff/patch) through Codex for adversarial second-opinion review. Use when the user explicitly asks for a Codex or second-opinion review of a plan, PRD, spec, design doc, or staged/committed code changes — or offer it before high-impact implementation. Do not trigger automatically on every document edit. ---

Codex Review

Use Codex as a read-only adversarial reviewer. Codex reads and reports — it does not modify files. Amendments require explicit user confirmation before being applied (documents) or are applied directly by Claude (code changes).

Two review modes:

• Document — review a markdown plan, PRD, spec, or design doc
• Code change — review a git diff, staged changes, or patch file

---

Step 1: Set up the workspace

Document mode

If the document is already a file on disk: note its absolute path.

If the document is in conversation only: write it to a temp file:

REVIEW_FILE=$(mktemp /tmp/codex-review-XXXXXX.md)
# write document content to $REVIEW_FILE

Determine the project root: check whether the document belongs to a git repo. If it does, use that repo root as the working directory for Codex — this lets it read related source files for context:

PROJECT_ROOT=$(git -C "$(dirname <absolute-path>)" rev-parse --show-toplevel 2>/dev/null || dirname <absolute-path>)

Code change mode

Capture the diff and write it to a temp file. Choose the right git diff invocation:

What to review Command Unstaged working-tree changes git diff Staged (index) changes git diff --staged Last commit git diff HEAD~1 HEAD Specific range git diff <ref1> <ref2> Already-a-patch-file use the file path directly

REVIEW_FILE=$(mktemp /tmp/codex-review-XXXXXX.diff)
git -C "$PROJECT_ROOT" diff --staged > "$REVIEW_FILE"   # adjust as needed
# verify it isn't empty before proceeding

Set PROJECT_ROOT to the git repo root so Codex can read surrounding source files for context:

PROJECT_ROOT=$(git rev-parse --show-toplevel)

---

Step 2: Build the review prompt

Adapt the focus based on what’s being reviewed. Always include the “do not modify files” constraint — --yolo grants write access, but this skill is review-only:

Input type Focus areas Implementation plan Flawed approach, missing steps, unclear dependencies, better alternatives PRD Requirements clarity, completeness, contradictions, missing edge cases, unstated assumptions Spec / design doc Ambiguity, testability, missing constraints, inconsistencies Code change Bugs and logic errors, security issues (injection, auth, data exposure), missing or broken error handling, test coverage gaps, unintended side effects, API / contract breaks, readability problems that will cause future bugs Other General clarity, gaps, and anything that would cause downstream failure

Use this template, filling in the input type and relevant focus areas:

You are an adversarial reviewer. The content is provided via stdin — it is a <input type>.
Your job is to find problems: <focus areas for this input type>.
Be specific — generic praise or vague concerns are not useful.
Do not modify, create, or delete any files. Read only.
End your review with one of these two verdicts as the very last line of your response:

APPROVED — the content is solid and ready to act on
NEEDS REVISION: <one-line summary of the main issue>

Write this prompt to a temp file:

PROMPT_FILE=$(mktemp /tmp/codex-review-prompt-XXXXXX.md)
# write prompt to $PROMPT_FILE

---

Step 3: Invoke Codex

Round 1 — start the session:

codex exec --yolo --cd "$PROJECT_ROOT" "$(cat $PROMPT_FILE)" < "$REVIEW_FILE"

After round 1 completes, capture the session ID from the session file. Session files are named rollout-...-<uuid>.jsonl and the resumable ID lives in the first line’s payload.id field:

LATEST_FILE=$(ls -t ~/.codex/sessions/$(date +%Y)/$(date +%m)/$(date +%d)/rollout-*.jsonl 2>/dev/null | head -1)
SESSION_ID=$(python3 -c "
import json, sys
with open('$LATEST_FILE') as f:
    for line in f:
        try:
            d = json.loads(line)
            sid = d.get('payload', {}).get('id', '')
            if sid:
                print(sid); break
        except: pass
" 2>/dev/null)

If SESSION_ID is empty, ask the user to provide it (visible in the Codex session picker) before proceeding.

Rounds 2–10 — resume the session. Write the resume prompt to a temp file and pipe it via stdin:

Document mode:

RESUME_FILE=$(mktemp /tmp/codex-review-resume-XXXXXX.md)
# write to $RESUME_FILE:
# "I've updated the document to address your concerns. Key changes: <summary>.
#  Please re-read the file at <absolute-path> and review again. Do not modify any files.
#  Use the same verdict format as before: APPROVED or NEEDS REVISION: <one-line summary>."

codex exec resume --yolo "$SESSION_ID" - < "$RESUME_FILE"

Code change mode:

# Re-capture the updated diff after applying fixes (see Step 5)
git -C "$PROJECT_ROOT" diff --staged > "$REVIEW_FILE"

RESUME_FILE=$(mktemp /tmp/codex-review-resume-XXXXXX.md)
# write to $RESUME_FILE:
# "The diff has been updated to address your concerns. Key changes: <summary>.
#  The updated diff is provided via stdin. Review it again. Do not modify any files.
#  Use the same verdict format: APPROVED or NEEDS REVISION: <one-line summary>."

codex exec resume --yolo "$SESSION_ID" - < <(cat "$RESUME_FILE" "$REVIEW_FILE")

• Run with run_in_background: true — Codex runs are long
• Read the output file directly as it streams; never pipe through tail or head
• Don’t hardcode a model name; Codex picks its default

---

Step 4: Parse the verdict

Look for the verdict only on the final line of Codex’s response — match strictly:

• Line starting with APPROVED → approved
• Line starting with NEEDS REVISION: → needs revision

Ignore any occurrence of these words mid-output; the prompt template or previous round context can produce false matches.

• APPROVED: surface Codex’s rationale to the user and confirm they want to proceed
• NEEDS REVISION:: surface the specific objections clearly, then go to Step 5

---

Step 5: Amend and resubmit

Document mode

Immediately amend the document to address Codex’s objections — no confirmation needed. Use judgment on what to change; not every objection requires a redesign. Tell the user what changed and why in one concise line, then go straight back to Step 3 (Round 2+).

Code change mode

Apply fixes directly to the source files (no confirmation needed for mechanical fixes; pause for architectural changes). Use judgment — not every objection warrants a change. Then:

1. Re-stage the fixed files (git add) so the updated diff reflects the corrections
2. Re-capture the diff: git diff --staged > "$REVIEW_FILE"
3. Tell the user what changed and why in one concise line
4. Go back to Step 3 (Round 2+), piping both the resume message and the fresh diff

Keep an iteration counter visible: “Review round 2”, “Review round 3”. This lets the user track progress and decide when to override.

Hard cap: 10 rounds. If Codex still hasn’t approved by round 10, stop the loop, surface the outstanding objections, and ask the user how to proceed.

---

Step 6: User override

The user can stop the loop at any point (“proceed anyway”, “I disagree with Codex here”). Codex’s verdict is advisory — surface it faithfully but respect the user’s final call.

3 个帖子 - 3 位参与者

阅读完整话题