S
SkillNav

commit_reviewer

by carpedx

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

View Chinese version with editor review

安装

claude skill add --url github.com/openclaw/skills/tree/main/skills/carpedx/commit-reviewer

必需命令行工具

bashgitfindsedgrepsort

文档

Commit Reviewer

适用场景

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

  • 这次提交有没有真正修复某个 bug
  • 这次提交是否覆盖了需求点
  • 这次提交代码有没有明显问题
  • 这次提交是否存在遗漏或潜在副作用

时使用本技能。

触发方式

优先识别以下形式：

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

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

例如：

text
/commit_reviewer 1f168bcd07a90c8b02f7a4eaf1809131df484185

或：

text
/commit_reviewer 1f168bcd07a90c8b02f7a4eaf1809131df484185 92ab33cdef00112233445566778899aabbccddee

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

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

例如：

text
/commit_reviewer yaf-ga-web-sht 1f168bcd07a90c8b02f7a4eaf1809131df484185

或：

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

方式三：指定项目路径

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

适用于：

  • 项目不在默认工作目录下
  • 希望跳过扫描，直接在某个仓库内检查
  • ClawHub 使用者目录结构不一致的情况

项目识别规则

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

1）用户显式指定项目名

如果命令格式为：

text
/commit_reviewer <project> <commit...>

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

默认工作目录优先级：

  1. 环境变量 COMMIT_REVIEWER_WORK_ROOT
  2. 当前目录

目录拼接规则：

text
<work_root>/<project>

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

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

3）用户未指定项目

如果命令格式为：

text
/commit_reviewer <commit...>

则走自动识别逻辑：

  1. 如果当前目录本身是 Git 仓库，则优先在当前项目中查找 commit
  2. 如果当前项目中找不到，则扫描默认工作目录下的多个 Git 仓库
  3. 如果只找到一个匹配项目，则直接使用该项目进行分析
  4. 如果找到多个匹配项目，则提示用户指定项目
  5. 如果未找到匹配项目，则提示用户检查 commit 是否正确，或补充项目名 / 项目路径

交互规则

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

必须先追问用户：

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

不要直接开始下结论。

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

必须先告诉用户：

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

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

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

必须先告诉用户：

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

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

必须先告诉用户：

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

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

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

分析目标

你需要结合：

  • 用户给出的需求 / bug 描述
  • entrypoint 提供的 git 提交上下文
  • 实际 diff 改动内容

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

强制分析规则

必须做到：

  1. 必须逐条对照需求检查
  2. 必须基于实际 diff 判断，不要只看 commit message
  3. 不要只因为“改了相关文件”就认定已修复
  4. 每个需求点必须输出以下四类结论之一：
    • 已解决
    • 可能已解决
    • 未解决
    • 无法判断
  5. 每条都要写清楚判断依据：
    • 改了哪些文件
    • 改的是哪类逻辑
    • 为什么这样判断
  6. 如果属于页面展示 / 前端交互 / UI 行为问题，必须补一句：
    • 代码层面看似已修复，但建议手测验证

风险判断要求

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

  • 是否只修了一部分
  • 是否可能引入副作用
  • 是否存在遗漏
  • 是否只是改了样式 / 文案，但没改核心逻辑
  • 是否排序、数量、关闭按钮、调用顺序这类问题只改了一半

输出格式

请严格按下面格式输出：

text
检查结果：

Commit:
- <commit1>
- <commit2>

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

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

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

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

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

重要限制

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

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

  • 弹窗顺序
  • 页面布局
  • 关闭按钮是否可点击
  • 前端列表排序展示是否与真实数据一致
  • 接口联调后才会生效的逻辑

运行约定（适合 ClawHub）

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

  • 优先通过环境变量指定工作目录：
text
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

语言风格

  • 中文输出
  • 简洁直接
  • 像真实开发评审结论
  • 不要空泛
  • 不要只复述 diff
  • 优先使用业务语言，而不是纯代码语言