Git commit
规范化 Git 提交信息。读取 git diff 理解代码改动意图,生成符合 Conventional Commits 规范的提交信息(英文 type + 中文描述),展示给用户确认后执行 git commit。在用户想要提交代码、生成提交信息、规范 commit message 时使用。中文触发词:提交、提交代码、commit、提交信息、git commit、生成 commit。From its SKILL.md
npx -y skills add zxc7563598/skillbox --skill git-commitAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
- runs commandsInstructs the agent to run 5 commands, including `git status --porcelain` and 4 more.
SKILL.md
7.5 KB, ~2.4k tokens by cl100k_base, as published. Nobody here has run it
Git Commit
一个帮助你生成规范化 Git 提交信息的技能。核心理念:理解改动意图,而非仅仅总结 diff。
核心能力
- 读取改动 — 获取
git diff和git status,全面了解待提交内容 - 理解意图 — 分析代码变更的真实目的,而不仅仅是看到的文本变化
- 规范生成 — 生成符合 Conventional Commits 规范的提交信息,type 使用英文,描述使用中文
- 用户确认 — 展示生成的提交信息,等待用户确认后才执行
git commit
重要:理解意图优先
这个技能不是为了"看一眼 diff 然后编一个看起来合理的 message"。它的价值在于:
- 透过改动看目的:删除一个函数可能不是"删除代码",而是在"移除已废弃的 API"
- 关联上下文:修改多个文件可能都是为了同一个功能,而不是零散的改动
- 正确分类 type:加一个 if 判断可能是
fix(修 bug)也可能是feat(加边界处理),需要理解为什么 - 用户提示是参考,不是答案:用户可能随口说"修了个问题",但实际改动是一次重构——以代码为准,用户提示只辅助理解
工作流程
第一步:获取改动信息
# 获取当前状态
git status --porcelain
# 获取未暂存的改动
git diff --no-color
# 获取已暂存的改动
git diff --cached --no-color
注意区分以下情况:
- 没有任何改动 → 告知用户,结束流程
- 只有已暂存的改动 → 只分析暂存区
- 只有未暂存的改动 → 分析工作区改动,commit 前需要
git add - 两者都有 → 分析全部改动,但告知用户当前状态
第二步:理解改动意图
在生成提交信息之前,花时间认真理解这次改动:
- 整体扫描:改动了哪些文件?文件之间有关联吗?
- 模式识别:
- 新增文件/函数/模块 → 可能是
feat - 修改条件判断、异常处理、边界情况 → 可能是
fix - 重命名、移动、结构调整但逻辑不变 → 可能是
refactor - 只改注释、文档、README → 可能是
docs - 测试文件的新增或修改 → 可能是
test - 配置、构建脚本、依赖更新 → 可能是
chore
- 新增文件/函数/模块 → 可能是
- 意图推断:这些改动作为一个整体想要达成什么目的?
- 用户提示:如果用户提供了提交信息文本——把它的语义当作理解意图的重要线索,但不要直接拿它当模板。用户写"修 bug"但你看到的是加了新功能,以代码为准。
第三步:生成提交信息
根据理解的意图,生成符合 Conventional Commits 规范的提交信息。
详见 references/conventional_commits.md 获取完整的类型说明和格式规范。
格式要求:
<type>(<scope>): <中文主题>
<中文正文>
基本规则:
- type 必须是小写英文:
feat,fix,refactor,docs,style,test,chore,perf,ci,build - scope 是可选的,用小写英文,表示影响的范围(模块、组件名等)
- 主题行用中文,简明扼要地描述改动目的(不是改动内容)
- 主题行不超过 50 个字符(中文约 25 个字)
- 主题和正文之间空一行
- 正文详细说明改了什么、为什么改,用中文
绝对禁止:
- 禁止在提交信息末尾添加任何署名或签名,包括但不限于
Co-Authored-By、Signed-off-by、Reviewed-by等。提交者信息由 git 的user.name和user.email配置自动记录,无需在 message 中重复 - 禁止在提交信息中写"生成者:Claude"、"由 AI 辅助生成"等 AI 相关声明
- 提交信息只包含改动相关的内容,不包含元信息
确定 type 的思考框架:
- 这个改动对外部用户可见吗?是新增能力吗?→
feat - 这个改动是在修复一个不希望存在的行为吗?→
fix - 这个改动既不增加功能也不修复 bug,但让代码更好维护了吗?→
refactor - 只影响文档吗?→
docs - 只影响测试吗?→
test - 只是格式、空格、分号等不影响逻辑的调整吗?→
style - 构建、依赖、CI 配置等维护性的改动吗?→
chore - 主要目的是提升性能吗?→
perf
示例:
输入:添加了 JWT 认证中间件,修改了路由配置
生成:
feat(auth): 添加 JWT 令牌认证功能
新增 JWT 验证中间件,在路由层拦截未认证请求。
支持令牌过期自动刷新,过期但未失效的令牌会触发静默刷新。
输入:修复了用户列表页分页数量不对的问题
生成:
fix(user): 修复分页总数计算错误
分页总数之前包含了已删除的用户,导致列表页显示的空页过多。
现在使用 COUNT(*) 替代 COUNT(id) 并过滤 deleted_at。
第四步:展示并确认
将生成的提交信息清晰展示给用户,然后使用 AskUserQuestion 工具让用户确认:
展示格式:
📋 建议的提交信息:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
feat(auth): 添加 JWT 令牌认证功能
新增 JWT 验证中间件,在路由层拦截未认证请求。
支持令牌过期自动刷新。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📂 将提交的文件:
M src/middleware/auth.js
M src/router/index.js
A src/utils/jwt.js
然后调用 AskUserQuestion,提供一个 3 选项的选择题:
- header: "确认提交"
- question: "是否使用此提交信息?"
- options:
"确认提交"— 使用此信息执行 git commit"我要修改"— 用户提供修改意见,基于反馈重新生成提交信息"取消"— 放弃,不执行任何操作
根据用户选择:
- 选 1 → 进入第五步,执行提交
- 选 2 → 读取用户的修改意见(在 answers 中),回到第三步重新生成
- 选 3 → 结束流程,告知用户"已取消"
第五步:执行提交
# 如果有未暂存的文件,先 add
git add <files>
# 执行提交
git commit -m "<subject>" -m "<body>"
提交成功后,显示提交的 hash 和分支信息。
特殊情况处理
用户提供了提交信息提示
当用户调用时附带了一些文字(如 /git-commit 修了个登录的bug):
- 把用户文字当作理解意图的重要线索,优先往用户说的方向上理解
- 但如果代码改动明显是别的类型,以代码为准,并向用户说明为什么
- 用户写的文字可能不规范——没关系,提取语义即可
- 即使用户提供了文字,仍然需要走完整的分析流程
改动过大
当 diff 超过 500 行时:
- 先按文件或目录分组
- 识别每组改动的主题
- 判断是否应该建议用户拆分成多个提交
- 如果属于同一主题,生成一个涵盖整体的提交信息
没有改动
直接告知用户:"当前工作区没有需要提交的改动。"
参考资源
references/conventional_commits.md— Conventional Commits 规范详解scripts/git_utils.sh— Git 操作辅助函数
What ships with it: 3 files
9.7 KB alongside SKILL.md, 1 of them executable
references/
- conventional_commits.md5.2 KB
scripts/
- git_utils.shruns1.6 KB
- README.md2.8 KB