Commit Reviewer

---

name: commit_reviewer

description: 根据一个或多个 git 修订号和需求描述，检查提交是否真正修复了对应 bug，并给出逐条结论

version: 1.1.0

entrypoint: scripts/collect_commit_context.sh

metadata:

openclaw:

requires:

bins: [bash, git, find, sed, grep, sort]

---

# Commit Reviewer

适用场景

当用户提供一个或多个 git commit hash，并希望你判断：

时使用本技能。

---

触发方式

优先识别以下形式：

方式一：不指定项目（自动识别）

/commit_reviewer <commit1> [commit2] [commit3] ...

例如：

/commit_reviewer 1f168bcd07a90c8b02f7a4eaf1809131df484185

或：

/commit_reviewer 1f168bcd07a90c8b02f7a4eaf1809131df484185 92ab33cdef00112233445566778899aabbccddee

方式二：指定项目（推荐）

/commit_reviewer <project> <commit1> [commit2] [commit3] ...

例如：

/commit_reviewer yaf-ga-web-sht 1f168bcd07a90c8b02f7a4eaf1809131df484185

或：

/commit_reviewer yaf-ga-web-sht 1f168bcd07a90c8b02f7a4eaf1809131df484185 92ab33cdef00112233445566778899aabbccddee

方式三：指定项目路径

/commit_reviewer /path/to/project <commit1> [commit2] [commit3] ...

适用于：

---

项目识别规则

本技能支持三种项目定位方式：

1）用户显式指定项目名

如果命令格式为：

/commit_reviewer <project> <commit...>

则只在默认工作目录下的对应项目目录中检查 commit，不再全局扫描。

默认工作目录优先级：

1. 环境变量 `COMMIT_REVIEWER_WORK_ROOT`

2. 当前目录

目录拼接规则：

<work_root>/<project>

2）用户显式指定项目路径

如果第一个参数看起来是一个存在的目录路径，则直接把它当作项目路径使用，只在该路径对应的 Git 仓库中检查 commit。

3）用户未指定项目

如果命令格式为：

/commit_reviewer <commit...>

则走自动识别逻辑：

1. 如果当前目录本身是 Git 仓库，则优先在当前项目中查找 commit

2. 如果当前项目中找不到，则扫描默认工作目录下的多个 Git 仓库

3. 如果只找到一个匹配项目，则直接使用该项目进行分析

4. 如果找到多个匹配项目，则提示用户指定项目

5. 如果未找到匹配项目，则提示用户检查 commit 是否正确，或补充项目名 / 项目路径

---

交互规则

1）如果用户只发了 commit，没有发需求描述

必须先追问用户：

我已经拿到 commit 了，请把这次要核对的需求 / bug 描述发给我，我会按需求逐条检查这些提交有没有真正修复。

不要直接开始下结论。

2）如果 commit 所属项目无法唯一确定

必须先告诉用户：

我找到了这个 commit，但它可能属于多个项目，或当前无法唯一确定项目。请补充项目名或项目路径后，我再继续检查。

不要在项目不明确的情况下强行下结论。

3）如果用户指定了项目，但项目不存在

必须先告诉用户：

我没有找到你指定的项目，请检查项目名是否正确，或补充更准确的项目路径。

4）如果用户指定了项目，但 commit 不属于该项目

必须先告诉用户：

我在你指定的项目中没有找到这个 commit，请确认 commit 是否正确，或检查项目是否填错。

5）如果用户同时发了 commit 和需求

直接开始检查，不要反复确认。

---

分析目标

你需要结合：

来判断这次提交是否真的修复了问题。

---

强制分析规则

必须做到：

1. 必须逐条对照需求检查

2. 必须基于实际 diff 判断，不要只看 commit message

3. 不要只因为“改了相关文件”就认定已修复

4. 每个需求点必须输出以下四类结论之一：

- 已解决

- 可能已解决

- 未解决

- 无法判断

5. 每条都要写清楚判断依据：

- 改了哪些文件

- 改的是哪类逻辑

- 为什么这样判断

6. 如果属于页面展示 / 前端交互 / UI 行为问题，必须补一句：

- 代码层面看似已修复，但建议手测验证

---

风险判断要求

除了判断“有没有修复”，还要顺带检查：

---

输出格式

请严格按下面格式输出：

检查结果：

Commit:
- <commit1>
- <commit2>

需求拆解：
1. ...
2. ...
3. ...

逐项检查：
1. <需求点>
- 结论：已解决 / 可能已解决 / 未解决 / 无法判断
- 依据：
- 风险/备注：

2. <需求点>
- 结论：
- 依据：
- 风险/备注：

总体结论：
- 本次提交整体是否覆盖需求
- 哪些点已处理
- 哪些点可能遗漏
- 是否建议手测

最终判断：
- 已修复 / 部分修复 / 未明显修复 / 需进一步验证

---

重要限制

你只能根据代码改动做“代码层面的修复判断”。

对于以下问题，必须提醒用户仍需手测验证：

---

运行约定（适合 ClawHub）

为避免不同机器目录结构不一致，建议：

COMMIT_REVIEWER_WORK_ROOT=/your/workspace/root

- 当前目录是 Git 仓库时，优先检查当前仓库

- 当前目录不是 Git 仓库时，默认扫描当前目录下的子仓库

- `COMMIT_REVIEWER_WORK_ROOT`：默认扫描根目录

- `COMMIT_REVIEWER_SCAN_DEPTH`：仓库扫描深度，默认 `4`

- `COMMIT_REVIEWER_PATCH_LINES`：每个 commit 输出的 patch 最大行数，默认 `1200`

---

语言风格