Menu
语言无关的 Code Review。支持本地变更和远程 PR。运行时自动发现已安装的语言/框架最佳实践 skill 并加载其规范。当存在 spec/需求文档时，同时审查实现完整性并批判性分析 spec 本身的缺陷。适用场景：(1) 用户要求 review 本地代码变更，(2) 用户提供 PR 编号或 URL 要求 review，(3) 用户提到 code review、审查代码等意图。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Claude 与 Codex 双视角 Code Review。并行执行 Claude review 和 Codex review（通过 codex exec CLI），对比分析后输出综合报告到 `.ai_docs/review/`。适用场景：(1) 用户要求双 agent 协作 review，(2) 用户手动明确触发该 skill。codex 永远不使用本 skill。
Claude 与 Codex CLI 协作编程模式。Claude 负责调研、规划、编写 prompt，所有代码编辑通过 Codex exec 执行。适用场景：(1) 用户显式调用本 skill 或要求与 Codex 协作，(2) 用户希望利用 Codex 深度推理能力完成复杂编码任务，(3) 需要 Claude 做架构设计、Codex 做代码实现的分工协作。进入后持续运行，直到用户明确退出。
旧版 PR 走读（HTML 输出），已被飞书版 pr-walkthrough 取代。仅在用户明确点名 legacy 版本或明确要求 HTML 报告时使用；常规的 PR / 分支解读请求一律走 pr-walkthrough。产出自包含的 HTML 走读报告——旅程式叙事、真实代码片段逐跳走读、排查路标（只做理解，不做 code review）。
PR / 分支变更深度解读。全量精读 diff 后在飞书文档中产出一份走查文档——旅程式叙事、画板图解、真实代码片段、排查路标，帮助项目 owner 重建对代码的理解与掌控（只做理解，不做 code review）。硬依赖 lark-cli 与 lark-doc / lark-whiteboard skill。适用场景：(1) 用户要求解读、理解某个 PR、分支或本地 diff 做了什么，(2) 用户给出 GitHub PR 链接或编号要求分析其设计与影响，(3) 大型变更（含 agent 代写的代码）合并前需要系统性摸清关键设计与流程。
Claude 与 Codex 双视角 Spec Review（代码驱动）。并行审查需求/设计产出物（proposal、specs、design、tasks 等），各自独立探索项目代码以验证 spec 的可行性和完整性，对比分析后输出综合报告到 `.ai_docs/review/`。适用场景：(1) 用户在 opsx:ff 后要求审查 spec 质量，(2) 用户要求双 agent 协作审查需求或设计文档，(3) 用户手动明确触发该 skill 并传入目标目录。codex 永远不使用本 skill。
文件驱动的结构化脑暴。只在用户直接触发时使用。适用场景：(1) 用户手动调用本 skill 并给出脑暴主题，(2) 用户要求对某个问题进行发散讨论和方案收敛。作为有立场的思维伙伴，通过逐个问题与用户碰撞观点，结论实时回写到脑暴文档。
| name | code-review |
| description | 语言无关的 Code Review。支持本地变更和远程 PR。运行时自动发现已安装的语言/框架最佳实践 skill 并加载其规范。当存在 spec/需求文档时，同时审查实现完整性并批判性分析 spec 本身的缺陷。适用场景：(1) 用户要求 review 本地代码变更，(2) 用户提供 PR 编号或 URL 要求 review，(3) 用户提到 code review、审查代码等意图。 |
语言无关的结构化 Code Review，支持本地变更和远程 PR。
判断审查对象类型：
gh 命令获取信息git 命令获取 diff如果用户未明确指定，检查当前工作区状态后询问。
检查 system-reminder 中的 skills 列表，识别与编码规范/最佳实践相关的 skill（如 go-coding、go-cli-tui 等）。
记住这些 skill 名称，后续读 diff 时按需加载。此步骤仅做识别，不立即读取 skill 内容。
根据审查目标类型获取变更内容：
远程 PR:
# 获取 PR 基本信息（标题、描述、分支、文件列表）
gh pr view <number> --json title,body,baseRefName,headRefName,files
# 获取已有评论和 review 意见，理解讨论历史
gh pr view <number> --comments
# 获取 diff
gh pr diff <number>
# 如需本地查看代码，checkout PR 分支
gh pr checkout <number>
阅读 PR 描述和已有评论，理解变更目标和讨论历史，避免重复已有反馈。
本地变更:
git status
# 已暂存的变更
git diff --cached
# 未暂存的变更（如果有）
git diff
# 如果用户指定了 commit 范围
git diff <base>..<head>
触发条件（满足任一即执行）：
执行内容：
实现完整性 Checklist:
Spec/需求文档缺陷分析:
未触发时跳过此步骤。
读取 review-checklist.md 作为审查基线。按以下优先级维度审查，只关注发现的问题，无问题的维度不输出：
| 优先级 | 维度 | 说明 |
|---|---|---|
| CRITICAL | Security | 注入、认证、敏感数据、依赖安全 |
| HIGH | Correctness | 逻辑、错误处理、边界、竞态 |
| HIGH | Performance | 查询、资源管理、算法效率 |
| MEDIUM | Maintainability | 清晰度、抽象、重复 |
| MEDIUM | Testing | 覆盖率、测试质量 |
最佳实践 Skill 加载： 读 diff 代码时，如果发现代码与 Step 2 记住的 skill 关联（如 .go 文件 → go-coding），读取该 skill 的 SKILL.md 和相关 references 作为审查背景知识。无关联 skill 时仅使用通用 checklist。加载的编码规范作为内部审查依据，不单独列出检查结果。
核心原则：只输出发现的问题，不输出通过项。 按三个层级分组，每层使用不同详细度：
## Summary
[一句话概括变更内容和整体评价]
## Spec Analysis (如果 Step 4 触发)
### 实现完整性
[checklist 结果]
### Spec 缺陷
[发现的问题]
## Critical
[必须修复的问题——完整四要素格式]
### 简短标题
- **位置**: file_path:line_number
- **问题**: 具体描述（标注所属维度如 Security / Correctness 等）
- **影响**: 不修复的后果
- **建议**: 具体修复方案
## Improvements
[建议改进但不阻塞合并——三要素格式]
### 简短标题
- **位置**: file_path:line_number
- **问题**: 具体描述
- **理由**: 为什么值得改（可选，如"与项目现有模式不一致"）
- **建议**: 具体改进方案
## Nitpicks
[风格、命名等品味级建议——轻量一行格式]
- `file_path:line_number` — 建议内容
## Verdict
[Approved / Request Changes / Needs Discussion]
[一句话说明理由]
输出规则：
gh pr checkout 会切换分支）询问用户是否需要生成一份结构化的 PR Reviewer 文档。如果用户同意，执行以下步骤：
综合以下来源提取背景信息：
git log 查看相关 commit 的 message生成背景说明的四个部分：
基于 Step 3 获取的 diff 信息，为每个变更的文件生成 1-2 句话的描述：
创建 markdown 文档，包含以下部分：
# PR Review Report
## 背景 (Context)
### 现状 (Current State)
[描述当前系统/代码的状态]
### 需求 (Requirements)
[说明为什么需要这个变更]
### 目标 (Goals)
[这个 PR 希望达到什么效果]
### 方案 (Approach)
[为什么选择这种实现方式]
## 变更概览 (Changes Overview)
**统计**: 修改 X 个文件，+Y/-Z 行
**文件变更**:
📝 path/to/file1.ext (+X, -Y)
→ [1-2 句话描述该文件的主要变更]
📝 path/to/file2.ext (+X, -Y)
→ [1-2 句话描述该文件的主要变更]
➕ path/to/new_file.ext (+X)
→ [1-2 句话描述新增文件的用途]
❌ path/to/deleted_file.ext (-X)
→ [1-2 句话描述删除原因]
## Review 结果 (Review Findings)
[复用 Step 6 的输出内容：Summary、Critical、Improvements、Nitpicks、Verdict]
## Spec 分析 (Spec Analysis)
[如果 Step 4 触发，复用其输出内容]
## 后续行动 (Action Items)
- [ ] [Critical] [具体问题描述]
- [ ] [High] [具体问题描述]
- [ ] [Medium] [具体问题描述]
- [ ] [Discussion] [需要讨论的问题]
PR_REVIEW_<number>.md（如 PR_REVIEW_123.md）CODE_REVIEW_<timestamp>.md（如 CODE_REVIEW_20260307.md）保存后告知用户文件路径。