review-branch-diff

分支差异代码审查 Skill

对比当前分支与目标分支的 diff，聚焦于当前分支引入的变更，生成结构化的代码审查报告。

参数解析

用户输入格式为以下之一：

1. <dst_branch> — 目标分支名，使用默认严格程度 normal
2. <dst_branch> <extent> — 目标分支名 + 严格程度（strict / normal / loose）
3. <自定义审查要求> — 当输入不匹配已知分支名时，视为自定义 prompt，需从中提取目标分支和审查偏好

若无法确定目标分支，直接询问用户。

工作流程

严格按以下步骤执行，不得跳过或合并步骤。

步骤 1：环境检查

执行以下命令验证环境并获取当前分支名：

git rev-parse --is-inside-work-tree
git rev-parse --abbrev-ref HEAD

若非 git 仓库，报错并终止。记录当前分支名，用于后续报告输出。

检查工作区是否有未提交的改动：

git status --porcelain

若输出非空，立即终止，输出以下提示：

⚠️ 存在未提交的改动

当前工作区有未提交的文件变更，这会影响 diff 的准确性。请先处理这些改动：

• 提交：git add . && git commit -m "<message>"
• 暂存：git stash
• 丢弃：git checkout -- .

处理完成后重新调用本 skill。

步骤 2：Rebase 状态校验（关键）

此步骤为硬性前置条件，必须通过后才能继续。

执行以下命令检查目标分支的最新提交是否已包含在当前分支中：

git merge-base --is-ancestor <dst_branch> HEAD

• 若退出码为 0：校验通过，说明当前分支已包含目标分支的所有提交，继续后续步骤。
• 若退出码为 非0：立即终止，输出以下错误信息：

⚠️ Rebase 检查失败

当前分支尚未包含 <dst_branch> 的最新提交。请先执行以下命令将目标分支的改动 rebase 到当前分支：

git pull --rebase origin <dst_branch>

rebase 完成且冲突解决后，重新调用本 skill。

步骤 3：获取差异

首先获取变更文件概览：

git diff <dst_branch>...HEAD --stat

注意使用三点语法 ...，这只会显示当前分支引入的变更，排除目标分支自身的改动。

如果 diff 输出为空，通知用户"当前分支与目标分支无差异"并终止。

然后按文件逐个获取 diff 进行分析：

git diff <dst_branch>...HEAD -- <file_path>

上下文补充：当 diff 片段不足以理解修改意图时（如修改了函数的部分逻辑、变更了类的某个方法），应主动读取相关源文件的完整上下文（函数体、类定义等），以避免脱离上下文的误判。

步骤 4：执行审查

根据严格程度调整审查深度：

级别	代号	审查范围
严格	strict	全面审查：逻辑错误、安全漏洞、性能问题、代码风格、可维护性、测试覆盖、边界条件
普通	normal	重点审查：逻辑错误、安全漏洞、性能问题、明显的代码异味
宽松	loose	仅审查：明显的逻辑错误、严重安全漏洞、会导致运行时崩溃的问题

审查原则（必须遵守）：

• 只审查 diff 引入的问题：如果某段代码在目标分支中已存在且本次 diff 未修改，不应对其提出问题。
• 关注变更的上下文：结合修改前后的代码理解意图，避免脱离上下文的误判。
• 区分严重程度：每个问题必须标注严重等级。

步骤 5：生成报告

严格按以下格式输出：

# 🔍 分支差异代码审查报告

**当前分支**：`<current_branch>`
**目标分支**：`<dst_branch>`
**审查严格程度**：<extent>
**变更概览**：<N> 个文件变更，+<additions> -<deletions>

---

## 📊 审查总结

| 严重等级 | 数量 |
|----------|------|
| 🔴 严重（Critical） | N |
| 🟠 重要（Major） | N |
| 🟡 建议（Minor） | N |
| 🔵 优化（Suggestion） | N |

**总体评价**：<一段话概括本次变更的质量和主要风险>

---

## 📋 详细审查

### [文件路径]

#### 问题 1：<问题标题>

- **严重等级**：🔴 严重 / 🟠 重要 / 🟡 建议 / 🔵 优化
- **所在行**：L<start>-L<end>
- **问题描述**：<具体说明问题是什么、为什么是问题>
- **建议修复**：



<!-- 对每个问题重复上述格式 -->

---

## ✅ 亮点

<!-- 列出 diff 中值得肯定的改动，如改进了错误处理、提升了可读性等。如无明显亮点可省略此节 -->

---

## 📝 审查结论

- **是否建议合并**：✅ 建议合并 / ⚠️ 修复后合并 / ❌ 需要重大修改
- **需要关注的文件**：<列出需要重点关注的文件>
- **后续建议**：<如有>

报告规范

• 每个问题必须引用具体的代码行号和文件路径。
• 建议修复 中的代码须可直接应用，不得使用伪代码或省略号。
• 若审查无问题发现，仍需输出报告框架并在总结中说明"未发现问题"。
• 使用用户项目的主要语言撰写代码注释，报告正文使用中文。