code-review

スター12

フォーク2

更新日2026年3月7日 09:02

语言无关的 Code Review。支持本地变更和远程 PR。运行时自动发现已安装的语言/框架最佳实践 skill 并加载其规范。当存在 spec/需求文档时，同时审查实现完整性并批判性分析 spec 本身的缺陷。适用场景：(1) 用户要求 review 本地代码变更，(2) 用户提供 PR 编号或 URL 要求 review，(3) 用户提到 code review、审查代码等意图。

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

ソース

figuretu

figuretu/my-skills

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Code Review

语言无关的结构化 Code Review，支持本地变更和远程 PR。

工作流程

Step 1: 确定审查目标

判断审查对象类型：

远程 PR: 用户提供 PR 编号或 URL → 使用 gh 命令获取信息
本地变更: 用户要求 review 本地代码 → 使用 git 命令获取 diff

如果用户未明确指定，检查当前工作区状态后询问。

Step 2: 扫描可用的最佳实践 Skill

检查 system-reminder 中的 skills 列表，识别与编码规范/最佳实践相关的 skill（如 go-coding、go-cli-tui 等）。

记住这些 skill 名称，后续读 diff 时按需加载。此步骤仅做识别，不立即读取 skill 内容。

Step 3: 准备上下文

根据审查目标类型获取变更内容：

远程 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>

Step 4: 需求与文档分析（条件执行）

触发条件（满足任一即执行）：

用户提及 spec、需求文档、设计文档
PR 描述中引用了 spec 或需求
diff 中包含文档文件（.md、spec、design doc 等）

执行内容：

检查 diff 中的文档变更
按需读取项目中的相关文档（docs/、README、spec 文件）理解上下文
产出两部分分析：

实现完整性 Checklist:

需求中的每个功能点是否都有对应实现
边界条件和异常场景是否已处理
文档描述与实际实现是否一致

Spec/需求文档缺陷分析:

歧义：描述模糊、可多种理解的条款
缺失：未覆盖的场景、缺少的约束条件
矛盾：文档内部或与实现之间的冲突
可测试性：需求是否可验证、验收标准是否明确
安全/性能盲区：未提及的安全要求或性能约束

未触发时跳过此步骤。

Step 5: 代码审查分析

读取 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。加载的编码规范作为内部审查依据，不单独列出检查结果。

Step 6: 输出审查结果

核心原则：只输出发现的问题，不输出通过项。 按三个层级分组，每层使用不同详细度：

## 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]
[一句话说明理由]

输出规则：

Critical 和 Improvements 中每个 finding 必须包含具体文件路径和行号
给出具体修改建议而非仅指出问题
空的层级不输出（如无 Critical 则省略该节）
无任何 finding 时仅输出 Summary + Verdict

Step 7: 收尾

远程 PR: 询问用户是否需要切回原分支（gh pr checkout 会切换分支）
本地变更: 无额外操作

Step 8: 生成 PR Reviewer 文档（可选）

询问用户是否需要生成一份结构化的 PR Reviewer 文档。如果用户同意，执行以下步骤：

8.1 收集背景信息

综合以下来源提取背景信息：

PR 描述: 从 Step 3 获取的 PR body
Commit Messages: 使用 git log 查看相关 commit 的 message
相关文档: 读取项目中的 spec、设计文档、README 等
用户补充: 如果自动提取的信息不足，询问用户补充背景说明

生成背景说明的四个部分：

现状 (Current State): 当前系统/代码的状态，存在什么问题或限制
需求 (Requirements): 为什么需要这个变更，业务/技术驱动因素
目标 (Goals): 这个 PR 希望达到什么效果，解决什么问题
方案 (Approach): 为什么选择这种实现方式，关键的技术决策

8.2 生成文件变更描述

基于 Step 3 获取的 diff 信息，为每个变更的文件生成 1-2 句话的描述：

分析每个文件的 diff 内容
总结该文件的主要变更意图
按目录/模块分组展示

8.3 生成完整文档

创建 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] [需要讨论的问题]

8.4 保存文档

远程 PR: 保存为 PR_REVIEW_<number>.md（如 PR_REVIEW_123.md）
本地变更: 保存为 CODE_REVIEW_<timestamp>.md（如 CODE_REVIEW_20260307.md）

保存后告知用户文件路径。

このリポジトリの他の Skills

同じリポジトリ

code-review-with-codex

figuretu/my-skills

Claude 与 Codex 双视角 Code Review。并行执行 Claude review 和 Codex review（通过 codex exec CLI），对比分析后输出综合报告到 `.ai_docs/review/`。适用场景：(1) 用户要求双 agent 协作 review，(2) 用户手动明确触发该 skill。codex 永远不使用本 skill。

2026-07-2812

cooperation-with-codex

figuretu/my-skills

Claude 与 Codex CLI 协作编程模式。Claude 负责调研、规划、编写 prompt，所有代码编辑通过 Codex exec 执行。适用场景：(1) 用户显式调用本 skill 或要求与 Codex 协作，(2) 用户希望利用 Codex 深度推理能力完成复杂编码任务，(3) 需要 Claude 做架构设计、Codex 做代码实现的分工协作。进入后持续运行，直到用户明确退出。

2026-07-2812

pr-walkthrough-legacy

figuretu/my-skills

旧版 PR 走读（HTML 输出），已被飞书版 pr-walkthrough 取代。仅在用户明确点名 legacy 版本或明确要求 HTML 报告时使用；常规的 PR / 分支解读请求一律走 pr-walkthrough。产出自包含的 HTML 走读报告——旅程式叙事、真实代码片段逐跳走读、排查路标（只做理解，不做 code review）。

2026-07-2812

pr-walkthrough

figuretu/my-skills

PR / 分支变更深度解读。全量精读 diff 后在飞书文档中产出一份走查文档——旅程式叙事、画板图解、真实代码片段、排查路标，帮助项目 owner 重建对代码的理解与掌控（只做理解，不做 code review）。硬依赖 lark-cli 与 lark-doc / lark-whiteboard skill。适用场景：(1) 用户要求解读、理解某个 PR、分支或本地 diff 做了什么，(2) 用户给出 GitHub PR 链接或编号要求分析其设计与影响，(3) 大型变更（含 agent 代写的代码）合并前需要系统性摸清关键设计与流程。

2026-07-2812

spec-review-with-codex

figuretu/my-skills

Claude 与 Codex 双视角 Spec Review（代码驱动）。并行审查需求/设计产出物（proposal、specs、design、tasks 等），各自独立探索项目代码以验证 spec 的可行性和完整性，对比分析后输出综合报告到 `.ai_docs/review/`。适用场景：(1) 用户在 opsx:ff 后要求审查 spec 质量，(2) 用户要求双 agent 协作审查需求或设计文档，(3) 用户手动明确触发该 skill 并传入目标目录。codex 永远不使用本 skill。

2026-07-2812

brainstorm

figuretu/my-skills

文件驱动的结构化脑暴。只在用户直接触发时使用。适用场景：(1) 用户手动调用本 skill 并给出脑暴主题，(2) 用户要求对某个问题进行发散讨论和方案收敛。作为有立场的思维伙伴，通过逐个问题与用户碰撞观点，结论实时回写到脑暴文档。

2026-03-1412

name

code-review

description

Code Review

语言无关的结构化 Code Review，支持本地变更和远程 PR。

工作流程

Step 1: 确定审查目标

判断审查对象类型：

远程 PR: 用户提供 PR 编号或 URL → 使用 gh 命令获取信息
本地变更: 用户要求 review 本地代码 → 使用 git 命令获取 diff

如果用户未明确指定，检查当前工作区状态后询问。

Step 2: 扫描可用的最佳实践 Skill

检查 system-reminder 中的 skills 列表，识别与编码规范/最佳实践相关的 skill（如 go-coding、go-cli-tui 等）。

记住这些 skill 名称，后续读 diff 时按需加载。此步骤仅做识别，不立即读取 skill 内容。

Step 3: 准备上下文

根据审查目标类型获取变更内容：

远程 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>

Step 4: 需求与文档分析（条件执行）

触发条件（满足任一即执行）：

用户提及 spec、需求文档、设计文档
PR 描述中引用了 spec 或需求
diff 中包含文档文件（.md、spec、design doc 等）

执行内容：

检查 diff 中的文档变更
按需读取项目中的相关文档（docs/、README、spec 文件）理解上下文
产出两部分分析：

实现完整性 Checklist:

需求中的每个功能点是否都有对应实现
边界条件和异常场景是否已处理
文档描述与实际实现是否一致

Spec/需求文档缺陷分析:

歧义：描述模糊、可多种理解的条款
缺失：未覆盖的场景、缺少的约束条件
矛盾：文档内部或与实现之间的冲突
可测试性：需求是否可验证、验收标准是否明确
安全/性能盲区：未提及的安全要求或性能约束

未触发时跳过此步骤。

Step 5: 代码审查分析

读取 review-checklist.md 作为审查基线。按以下优先级维度审查，只关注发现的问题，无问题的维度不输出：

优先级	维度	说明
CRITICAL	Security	注入、认证、敏感数据、依赖安全
HIGH	Correctness	逻辑、错误处理、边界、竞态
HIGH	Performance	查询、资源管理、算法效率
MEDIUM	Maintainability	清晰度、抽象、重复
MEDIUM	Testing	覆盖率、测试质量

Step 6: 输出审查结果

核心原则：只输出发现的问题，不输出通过项。 按三个层级分组，每层使用不同详细度：

## 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]
[一句话说明理由]

输出规则：

Critical 和 Improvements 中每个 finding 必须包含具体文件路径和行号
给出具体修改建议而非仅指出问题
空的层级不输出（如无 Critical 则省略该节）
无任何 finding 时仅输出 Summary + Verdict

Step 7: 收尾

远程 PR: 询问用户是否需要切回原分支（gh pr checkout 会切换分支）
本地变更: 无额外操作

Step 8: 生成 PR Reviewer 文档（可选）

询问用户是否需要生成一份结构化的 PR Reviewer 文档。如果用户同意，执行以下步骤：

8.1 收集背景信息

综合以下来源提取背景信息：

PR 描述: 从 Step 3 获取的 PR body
Commit Messages: 使用 git log 查看相关 commit 的 message
相关文档: 读取项目中的 spec、设计文档、README 等
用户补充: 如果自动提取的信息不足，询问用户补充背景说明

生成背景说明的四个部分：

现状 (Current State): 当前系统/代码的状态，存在什么问题或限制
需求 (Requirements): 为什么需要这个变更，业务/技术驱动因素
目标 (Goals): 这个 PR 希望达到什么效果，解决什么问题
方案 (Approach): 为什么选择这种实现方式，关键的技术决策

8.2 生成文件变更描述

基于 Step 3 获取的 diff 信息，为每个变更的文件生成 1-2 句话的描述：

分析每个文件的 diff 内容
总结该文件的主要变更意图
按目录/模块分组展示

8.3 生成完整文档

创建 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] [需要讨论的问题]

8.4 保存文档

远程 PR: 保存为 PR_REVIEW_<number>.md（如 PR_REVIEW_123.md）
本地变更: 保存为 CODE_REVIEW_<timestamp>.md（如 CODE_REVIEW_20260307.md）

保存后告知用户文件路径。