Menu
语言无关的 Code Review。支持本地变更和远程 PR。运行时自动发现已安装的语言/框架最佳实践 skill 并加载其规范。当存在 spec/需求文档时，同时审查实现完整性并批判性分析 spec 本身的缺陷。适用场景：(1) 用户要求 review 本地代码变更，(2) 用户提供 PR 编号或 URL 要求 review，(3) 用户提到 code review、审查代码等意图。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
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）保存后告知用户文件路径。