用途：审查指定 PR，先对照其关联 issue 的需求（验收标准、目标、约束）判断实现是否达标，再评估代码质量，最后以 GitHub review 形式发布结构化反馈。除发布审查评论外全程只读，不改代码、不提交。
调用方式：/oh-review <pr-number>，参数为要审查的 PR 编号。
前置条件：在 PR 所在仓库根目录运行；GitHub CLI（gh）需已认证。
主要流程：先从 AGENTS.md 与相关 .oh/ 产物加载项目背景，优先用 RNA repo_map 和 search 探索仓库；若 RNA 为空或不完整，则放宽查询、移除过滤，并在回退到 Read/Grep/Bash 前记录原因与摩擦事件。随后用 gh pr view 获取 PR 元数据，PR 非 open 则中止；从 PR 正文解析 Closes/Fixes/Resolves #N 并读取完整 issue，提取验收标准、目标、上下文与约束；若无关联 issue，则注明无法验证需求，仅审查代码质量。再用 gh pr diff 获取差异，依次对照 issue 需求、代码质量（缺陷、错误处理、边界情况）、仓库既有模式一致性、缺失的测试或文档。
审查输出：写入临时文件，结构包含 Requirements Check（逐条验收标准标注 met/not met/partially met）、Blockers（P0-P1）、Improvements（P2-P3）、Clean、Follow-up Work。存在阻塞项或需求未满足时用 gh pr review <pr-number> --request-changes --body-file /tmp/review-<pr-number>.md；无阻塞且需求满足时用 --approve。完成后必须调用 signal_completion：成功无阻塞为 success，有阻塞为 blocked，不可恢复失败为 error；若该工具不可用，则以 COMPLETION: status=... 格式输出最终状态。
原则与限制：issue 即规格，仅通过代码审查但遗漏需求视为失败；区分阻塞项、改进项与细节；需阅读完整 diff；跟进项应具体到可独立成 issue，但不自动创建 issue，由人工决定；保持只读。退出条件为审查已发布并批准、审查已发布并请求修改、或无法获取 PR/diff/发布审查而报错。