Smart Commit

Security

智能 Git 提交信息生成工具。根据代码 diff 自动生成规范的 commit message、PR 描述和 Release Notes。 **当以下情况时使用此 Skill**: (1) 需要根据代码变更生成 commit message (2) 需要编写 PR/MR 描述 (3) 需要生成 Release Notes / Changelog (4) 用户提到"commit"、"提交"、"PR描述"、"changelog"、"发布说明" (5) 想让 git log 更规范、更有价值 (6) 需要分析代码变更的影响范围

Install

openclaw skills install ai-smart-commit

📝 Smart Commit — 智能 Git 提交信息生成

让每一次 commit 都有灵魂,不再 git commit -m "fix bug"

🎯 核心功能

  1. Commit Message 生成 — 分析 diff,输出符合 Conventional Commits 规范的提交信息
  2. PR 描述生成 — 自动生成结构化的 Pull Request 描述(变更摘要、影响范围、测试建议)
  3. Release Notes 生成 — 汇总多个 commit,生成面向用户的版本更新说明
  4. 变更影响分析 — 评估代码变更的风险等级和影响范围

📋 使用方式

模式一:Commit Message 生成

当用户提供代码 diff 或描述变更内容时,执行以下流程:

1. 读取 diff 或变更描述
2. 分析变更类型(feat/fix/refactor/docs/style/test/chore/perf)
3. 识别影响范围(哪些模块/文件受影响)
4. 判断是否为 BREAKING CHANGE
5. 生成 commit message

输出格式:

<type>(<scope>): <description>

[可选 body:详细说明为什么这样做]

[可选 footer:BREAKING CHANGE / 关联 issue]

模式二:PR 描述生成

当用户要求生成 PR 描述时:

1. 收集所有相关 commit
2. 按功能分组(新功能/修复/重构/文档)
3. 评估风险等级
4. 生成结构化 PR 描述

输出格式:

## 📌 变更摘要
[一段话概括这个 PR 做了什么]

## 🔧 主要变更
- **[类型]** 具体变更1
- **[类型]** 具体变更2
- ...

## 📁 影响范围
- `path/to/file` — 变更说明
- ...

## ⚠️ 风险评估
[低/中/高] — 说明原因

## ✅ 测试建议
- [ ] 测试项1
- [ ] 测试项2

## 🔗 相关
- Closes #xxx

模式三:Release Notes 生成

当用户要求生成 Release Notes 或 Changelog 时:

1. 收集版本区间内所有 commit
2. 按类型分组(Features/Bug Fixes/Breaking Changes/其他)
3. 过滤无意义的 commit(如 "wip"、"fix typo")
4. 生成面向用户的版本说明

输出格式:

## [版本号] - 日期

### ✨ 新功能
- 具体功能1
- 具体功能2

### 🐛 修复
- 具体修复1

### 💥 破坏性变更
- 具体变更及迁移指南

### 🔧 其他改进
- 具体改进

模式四:快速模式

当用户只是快速问"帮我写个 commit message"时:

直接输出一行或三行 commit message,不输出额外解释。提供 2-3 个选项让用户选择。


🧠 Commit 规范

Type 枚举

Type用途示例
feat新功能feat(auth): add OAuth2 login support
fix修复 bugfix(api): handle null response from upstream
refactor重构(不改变功能)refactor(utils): extract date formatting to helper
docs文档变更docs(readme): update installation guide
style代码格式(不影响逻辑)style(lint): fix indentation in auth module
test测试相关test(auth): add unit tests for token refresh
chore构建/工具链chore(deps): upgrade webpack to v5
perf性能优化perf(query): add index for user search
ciCI/CD 变更ci(github): add macOS build target
build构建系统build(webpack): configure code splitting

Scope 建议

Scope 应该是模块名或功能域,不要用文件名:

  • auth, api, db, ui, payment
  • index.js, controller, model

风格规则

  1. subject 行:不超过 72 字符,用祈使句("add" 不用 "added")
  2. body:说明「为什么」而不是「做了什么」(diff 已经展示了做了什么)
  3. 中文项目:subject 可以用中文,但 type 和 scope 保持英文
  4. 避免无意义 commit:不要生成 fix: update code 这种废话

中英文选择

根据项目语言自动判断:

  • 项目 README/代码注释是中文 → commit message 用中文
  • 项目是英文 → commit message 用英文
  • 用户明确要求 → 跟用户走

🔄 变更分析规则

影响范围判定

变更模式影响范围风险等级
只改文档/注释🟢 低
新增独立功能模块局部🟢 低
修改工具函数/公共组件广泛🟡 中
修改 API 接口/数据模型全局🔴 高
修改配置文件/构建脚本全局🟡 中
修改认证/权限逻辑全局🔴 高
数据库 migration数据层🔴 高

BREAKING CHANGE 判断

以下情况标记为 BREAKING CHANGE:

  • 删除或重命名公开 API
  • 修改函数签名(参数/返回值)
  • 修改配置文件格式
  • 修改数据库 schema
  • 升级主要依赖版本

💡 使用技巧

自动获取 diff

如果用户在工作目录中有 git 仓库,主动建议:

# 查看暂存区变更
git diff --cached

# 查看工作区变更
git diff

# 查看最近一次 commit
git show HEAD

批量 commit 整理

当用户说"帮我整理一下这周的 commit"时:

  1. git log --oneline --since="1 week ago" 获取 commit 列表
  2. 合并同类 commit
  3. 生成整理后的 commit message 建议

与代码审查结合

生成 commit message 后,可以顺便做:

  • 检查是否有遗漏的文件
  • 建议需要补充的测试
  • 提示潜在的副作用

📌 质量检查清单

生成的 commit message 必须满足:

  • Type 准确反映变更性质
  • Scope 合理(不过宽也不过窄)
  • Subject 清晰描述了"做了什么"
  • Body 解释了"为什么这样做"(如果需要)
  • 没有废话("update code"、"fix stuff")
  • 中英文与项目风格一致