# Codex Claude Peer Review > Use when the user explicitly wants Codex and Claude Code to consult, challenge each other, get a second opinion, or converge on high-confidence evidence; also use for high-risk root-cause analysis, architecture decisions, implementation plans, PR/MR merge or blocker judgments, ship or rollback decisions, security/data/operations risk, or prompts mentioning Claude review, Codex review, 会诊, 互审, 双方都… - **Type:** Skill - **Install:** `agentstack add skill-yoshiyukisakura-codex-claude-peer-review-codex-claude-peer-review` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [YoshiyukiSakura](https://agentstack.voostack.com/s/yoshiyukisakura) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [YoshiyukiSakura](https://github.com/YoshiyukiSakura) - **Source:** https://github.com/YoshiyukiSakura/codex-claude-peer-review ## Install ```sh agentstack add skill-yoshiyukisakura-codex-claude-peer-review-codex-claude-peer-review ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Codex Claude Peer Review Run a bounded Codex plus Claude Code review loop. Treat the second model as an adversarial reviewer, not as proof. Converge only when evidence resolves the important disagreements or the remaining risk is explicitly recorded. ## Fast Path 1. Classify the request as execution, investigation, decision, or communication. 2. State success criteria before external review: target outcome, reliability requirements, and evidence sources. 3. Build Codex's first pass from real artifacts: repo, diff, runtime, logs, browser state, CI, PR/MR, issue, database, or source material. 4. Send Claude a narrow attack-review request when Codex starts the loop. If Claude already provided the first pass, do not call Claude again. 5. Triage the external review into blockers, material concerns, optional improvements, invalid objections, and residual risks. 6. Gather more evidence only when it can change the decision. 7. Return the converged result with a clear state label: planned, edited, locally tested, browser/runtime verified, CI verified, externally confirmed, blocked, or residual risk accepted. ## Operating Modes - Codex starts the loop: - Inspect the real artifact first. - Produce a first-pass plan, diagnosis, implementation summary, or verdict. - Send Claude a scoped challenge prompt. - If Claude is unavailable after valid invocation attempts, use Kimi fallback and label it clearly. - Claude or Kimi already provided the first pass: - Treat that output as the artifact under review. - Attack assumptions, evidence gaps, edge cases, regression risk, overclaims, and weak verification. - Do not launch another Claude or Kimi pass from this mode. - Both sides already responded: - Re-check accepted, rejected, and still-open points. - Stop when key disagreements are resolved, remaining risks are explicit, or more work needs user authorization. ## Trigger Discipline - Use proactively only when a wrong answer could create delivery, merge, architecture, security, data, financial, customer, or operational risk. - Do not spend a peer-review loop on simple summaries, routine edits, low-risk factual answers, or mechanical formatting unless the user asks for it. - If the user asks for a plan only, review and improve the plan without making code changes. - If the user asks for execution, keep moving after convergence unless a credential, destructive action, external approval, or unresolved blocker requires user input. ## Evidence Package Before calling Claude, prepare a compact evidence package with: - Scope: exact repo, worktree, branch, PR/MR, issue, service, port, URL, database, file, or artifact identifiers. - User goal: the outcome the user actually asked for. - Success criteria: what must be true before the answer can be trusted. - Codex first pass: conclusion plus confidence, or implementation plan plus risk. - Evidence gathered: commands, tests, logs, screenshots, browser/runtime proof, CI, external state, and file references. - Known unknowns: facts not yet verified and why they matter. - Safety constraints: no secrets in prompts, no production mutation unless already authorized, and no unrelated file changes. Do not paste API keys, tokens, passwords, private customer data, or unnecessary proprietary content into Claude or Kimi prompts. Replace secrets with variable names only, and say that redaction occurred. ## Claude Invocation From Codex Use the local Claude Code CLI only when Codex starts the loop. Verify current CLI flags with `claude --version` and `claude -p --help` when the environment looks stale, flags fail, or the final answer depends on exact model or permission behavior. Difficulty routing: - High difficulty: - Request CLI model alias `opus` with `xhigh` effort when available. - If `opus` is unavailable, rerun with `sonnet` and `high` effort, or the strongest currently documented alias shown by `claude -p --help`, then report the actual fallback command. - Use for architecture decisions, difficult root-cause analysis, risky merge/blocker judgments, cross-system workflows, security-sensitive work, and high-impact conclusions. - Medium difficulty: - Request CLI model alias `opus` with `xhigh` effort. - If `opus` is unavailable or too slow for the task, reroute to `sonnet` with `high` effort and record the fallback. - Use for normal investigations, implementation review, PR/MR review, localized technical decisions, and moderate-risk plans. - Low difficulty: - Skip Claude unless the user asked for bilateral review or the task becomes riskier than it first appeared. - If Claude review is requested for a low-risk task, route it as medium difficulty. Use one of these command patterns. Strict no-tool review, preferred when the evidence package fits in the prompt: ```bash claude -p --verbose --model opus --effort xhigh --output-format stream-json --include-partial-messages --tools "" --no-session-persistence "$REVIEW_PROMPT" ``` Fallback when `opus` is unavailable: ```bash claude -p --verbose --model sonnet --effort high --output-format stream-json --include-partial-messages --tools "" --no-session-persistence "$REVIEW_PROMPT" ``` Read-only file review, used when Claude must inspect local files: ```bash claude -p --verbose --model opus --effort xhigh --output-format stream-json --include-partial-messages --tools Read,Grep,Glob --permission-mode plan --no-session-persistence "$REVIEW_PROMPT" ``` Legacy read-only route, used only when the local CLI does not support `--tools` as expected: ```bash claude -p --verbose --model opus --effort xhigh --output-format stream-json --include-partial-messages --permission-mode plan --disallowedTools Bash,Edit,Write,NotebookEdit --no-session-persistence "$REVIEW_PROMPT" ``` Rules for invocation: - Do not pass marketing names, display strings, private model codenames, or unreleased model identifiers to `--model`; use public CLI aliases such as `opus` or `sonnet` that are accepted by the local `claude -p --help` output. - Treat model aliases as requests, not guarantees. If the CLI rejects a model, record the rejected alias and the actual fallback command. - Do not include `MultiEdit` in `--disallowedTools`; this local Claude CLI has rejected that tool name in prior use. - Prefer `--tools ""` for pure prompt review because it prevents file writes, shell commands, and subagent delegation. - If Claude requests an out-of-scope tool, tries to write files during read-only review, or launches a subagent that cannot access required evidence, interrupt or stop the run. Treat any partial output as a signal to check, not as a completed peer review. - Do not imply Claude changed models when the run happened inside an already-open Claude session. Record the actual model/effort if visible; otherwise say it was not verified. ## Kimi Fallback Use Kimi only when Claude Code is unavailable, fails after valid flags, lacks model access, is blocked by permission/session limits, or remains unavailable after the wait policy. Kimi fallback command: ```bash kimi -p "$REVIEW_PROMPT" --output-format stream-json ``` If JSONL streaming is awkward in the shell: ```bash kimi -p "$REVIEW_PROMPT" ``` Rules for fallback: - Label the review as `Kimi fallback`. - Use the same attack-review prompt shape used for Claude. - Do not claim Codex plus Claude convergence when Kimi was the reviewer. - Lower confidence unless independent evidence closes the risk. - Do not combine Kimi prompt mode with `--plan`; this CLI has rejected that combination. - If both Claude and Kimi are unavailable, stop and report that independent review could not be completed. ## Long-Running Review Handling - Do not treat 3 to 5 minutes of silence as a hang. - For high-difficulty review, wait at least 10 minutes before considering the run stalled. - For very large diffs, architecture reviews, and `xhigh` effort runs, 10 to 20 minutes can still be normal. - Prefer streaming output and poll the same shell session. Do not start duplicate Claude runs for the same review. - Abort early only on explicit CLI errors, invalid flags, permission failure, out-of-scope tool use, user cancellation, or clear evidence that the run cannot access the needed artifacts. - If there is no useful output after the wait window, say `Claude review still pending or stalled`; do not present it as completed peer review. ## Review Prompt Shape Use direct field labels instead of broad requests: ```text You are the independent reviewer in a Codex plus Claude Code peer-review loop. Task: summarize the user's goal in one sentence. Difficulty: high, medium, or low. Codex first pass: state the current plan, implementation summary, diagnosis, or verdict. Evidence gathered: list exact commands, files, logs, browser/runtime proof, CI, screenshots, or external state already checked. Known unknowns: list uncertain facts and why they matter. Tool boundary: do not edit files, do not write plan files, do not run shell commands, and do not spawn subagents unless explicitly allowed in this prompt. Please attack this result. Focus on missing evidence, wrong assumptions, edge cases, regression risks, overclaims, better alternatives, and verification gaps. Separate blockers from material concerns and optional improvements. Do not rewrite the answer unless rewriting exposes a concrete flaw. ``` If Claude must read local files, add exact allowed paths and keep the tool boundary limited to `Read`, `Grep`, and `Glob`. ## Reviewer Response Triage - Blocker: would change a merge, ship, rollback, security, data, or user-facing decision. - Material concern: should change implementation, tests, evidence, or wording before final delivery. - Optional improvement: useful but not required for the current goal. - Invalid objection: contradicts verified evidence or depends on a false premise. - Residual risk: plausible but not currently verifiable, or not worth further work for the user's goal. Accept reviewer points only when supported by evidence or strong technical reasoning. Reject points by citing the verified fact they contradict. Gather more evidence before concluding if a material disagreement depends on facts. ## Post-Review Changes - If Codex changes the implementation, evidence artifact, screenshot ordering, report generation, or final wording after Claude/Kimi review, disclose that change in the final convergence summary. - Do not imply the reviewer saw a post-review change that was made after the review completed. - Rerun external review only when the post-review change can alter correctness, safety, mergeability, live behavior, or the core conclusion. - For low-risk presentational or evidence-packaging fixes, it is acceptable to skip a second external review, but label them as post-review local adjustments. ## Evidence Rules - Prefer live repo, runtime, browser, CI, logs, database state, or external-system proof over model agreement. - Do not treat `message sent`, `delivery confirmed`, `agent busy`, and `agent executed with visible output` as equivalent. - Do not call work done because both models agree. Call it done only when success criteria are met or remaining risk is explicit and acceptable. - Do not overclaim a validated slice as full completion of the upstream goal. - Preserve exact repo, worktree, issue, PR/MR, branch, port, command, artifact, and URL identifiers when they matter. ## State Labels Use these labels for execution tasks: - Planned: approach exists, no file/runtime change verified. - Edited: changes made, verification not yet run or not yet passed. - Locally tested: local tests or scripts passed. - Browser/runtime verified: user-visible or running-system proof was checked. - CI verified: remote CI or pipeline passed. - Externally confirmed: GitHub/GitLab/deploy/customer-facing state was checked. - Blocked: same blocker remains after reasonable attempts or required input is missing. - Residual risk accepted: unresolved risk remains, but it is explicit and acceptable for this decision. ## Example User request: `找 Claude 会诊一下这个 MR 能不能 merge。` 1. Codex inspects the MR, diff, CI, tests, runtime/browser proof, and open review state. 2. Codex writes a first-pass verdict: `Do not merge yet; one stale-row blocker remains after failed refresh.` 3. Codex sends Claude a narrow attack prompt with exact evidence and allowed read-only scope. 4. Claude challenges missing tests, downgrade risks, stale assumptions, or overclaims. 5. Codex accepts or rejects each point based on evidence, gathers more proof if it can change the verdict, and returns a final merge/block decision. ## Final Output Contract Default to this concise shape unless the user requests another format: ```md ## Final conclusion Answer plus confidence: high, medium, or low. ## Evidence - Verified facts and proof. ## External review Claude model and effort requested, actual model if visible, fallback if any, post-review changes not reviewed, and main objections. ## Convergence - Accepted: reviewer points adopted and why. - Rejected: reviewer points rejected and why. - Still open: residual risks or unknowns. ## Next step Execute, merge, block, investigate, ask for a specific decision, or report complete. ``` For communication deliverables, convert the converged result into the requested audience's language after the peer-review loop. Use Chinese when the user asks for `中文报告`; use polished English for external GitHub/GitLab reviewer-facing text unless instructed otherwise. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [YoshiyukiSakura](https://github.com/YoshiyukiSakura) - **Source:** [YoshiyukiSakura/codex-claude-peer-review](https://github.com/YoshiyukiSakura/codex-claude-peer-review) - **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:** no - **Shell / process execution:** no - **Environment & secrets:** no - **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-yoshiyukisakura-codex-claude-peer-review-codex-claude-peer-review - Seller: https://agentstack.voostack.com/s/yoshiyukisakura - 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%.