/review

name: xreview
description: >
  MANDATORY for ALL code review requests. When the user asks to "review", "code review",
  "check code", "找 bug", "review 程式碼", or any variation of reviewing code for bugs,
  security issues, or quality — you MUST use this skill. Do NOT read files and review
  them yourself. This skill delegates review to Codex (a separate AI reviewer) via the
  xreview CLI, enabling three-party review (Codex reviews, Claude Code verifies, user decides).
  Default mode is review-only: present all findings, let user discuss, then fix on demand.
allowed-tools: Bash(xreview *), Bash(curl *), Bash(which *), AskUserQuestion, Read, Write, Skill
argument-hint: [files-or-uncommitted]

xreview - Agent-Native Code Review

<CRITICAL> You MUST use this skill for ANY code review task. NEVER review code by reading files yourself. The entire point of xreview is to delegate review to Codex (a separate AI model) so you get an independent second opinion. If you skip this skill and review code yourself, you defeat the purpose — you're reviewing your own work instead of getting an external review. </CRITICAL>

Supported Languages for --language

| Key | Language | |-------|----------| | `cpp` | C++ | | `go` | Go |

If review targets are written in a supported language, add `--language <key>`. If unsure or mixed languages, omit `--language` — xreview falls back to general-purpose review. Only use keys from the table above.

Step 0: Preflight

Run: `xreview preflight`

This single command checks everything: xreview version, codex installation, API key.

Parse the XML output:

• If status="success": proceed to Step 1.
• If status="error": show the user the error message from the <error> tag.

Relay it in natural language and suggest how to fix it. Stop.

If xreview itself is not found (`which xreview` fails): a. Ask the user "xreview is not installed. Install it now? (y/n)" b. If yes: run `curl -fsSL https://raw.githubusercontent.com/davidleitw/xreview/master/scripts/install.sh | bash` then re-run preflight. c. If install fails: tell the user to check https://github.com/davidleitw/xreview/releases. Stop.

Step 1: Determine review targets and assemble context

Two review modes — pick the one that fits:

Mode A: Review uncommitted changes (`--git-uncommitted`)

Use when reviewing what's about to be committed. Codex will run `git diff` to see the changes itself.

Mode B: Review specific files (`--files`)

Use when:

• Reviewing a single file's quality (not tied to a git change)
• Reviewing a flow/feature that spans multiple files
• The user specifies which files to look at
• You just completed a plan with specific files changed

Codex will read the files directly — no git diff involved.

Assembling `--context`

The context string is critical — it tells Codex **what to focus on** and provides background for the final review report. Include as much relevant context as you have.

For **git-uncommitted** (change-focused):

--context "【背景】why this change is being made — the motivation or problem being solved
【變更類型】feature | refactor | bugfix
【描述】what was changed — specific functions, modules, or behaviors modified
【進度】current status — e.g. 'implementation complete, pre-commit review' or 'WIP, reviewing direction'
【預期行為】what this code should achieve (for refactor: 'behavior should be identical to before')
【未完成】anything not yet done or known limitations, if applicable"

For **files** (flow/feature review):

--context "【背景】why this review is needed — e.g. 'new feature ready for review', 'investigating production bug'
【Review 焦點】what to focus on — e.g. 'Review the CMS push event flow:
enqueue → EventQueue.push() → purge logic → SendQueue routing.
Focus on concurrency safety and lock correctness across these files.'
【進度】current status of the work
【預期行為】expected behavior — e.g. 'cache and ordered paths are fully independent, no cross-locking'"

For **files** (single file quality):

--context "【背景】why reviewing this file — e.g. 'recently refactored, want quality check'
【Review 焦點】General quality review of event_queue.cpp.
Look for bugs, race conditions, error handling issues.
【進度】current status"

The better the context, the better Codex's review AND the better the final report. Be specific about the flow direction, expected behavior, and areas of concern. Include background motivation — this gets stored in the session and used when generating the review report.

Step 2: Run review

Run: `xreview review --files <paths> --context "<structured context>"` [--language <key>] or: `xreview review --git-uncommitted --context "<structured context>"` [--language <key>]

Add `--language` only when the review targets match a supported language (see table above).

Step 2.5: Verify + Present

<CRITICAL>

• You MUST independently verify EVERY finding before presenting to the user.
• Do NOT blindly copy Codex output. You are a capable code reviewer — USE your judgement.
• The xreview output includes `<agent-instructions>` after `</xreview-result>`. Follow them.

</CRITICAL>

Parse the XML output from Step 2.

If verdict is APPROVED (zero findings): tell the user "No issues found." Skip to Step 5.

Phase 1: Verify Each Finding

Group findings by file. For each file, read it ONCE, then verify all findings in that file.

For EACH finding:

1. **Read the actual code** at the file:line (reuse the file content if already read for another finding in the same file). 2. **Analyze validity** — does the issue actually exist?

• For concurrency/lock findings: check lock scope (nested vs sequential locking),

whether locks are actually held simultaneously, real contention scenarios.

• For logic findings: trace the actual code path end-to-end.
• For security findings: confirm untrusted input actually reaches the vulnerable code.

3. **Classify**:

• **CONFIRMED**: the issue is real, you verified it in the code.
• **SUSPECT**: you believe it may