Commit Message

工作流程

1. 优先读取当前仓库作用域内的 AGENTS.md 和提交规范；若项目规则与本 Skill 冲突，以项目规则为准。
2. 根据用户提供的变更说明生成消息。上下文不足且当前目录是 Git 仓库时，先检查变更：
   • 先运行 git status --short；
   • 有暂存变更时，以 git diff --cached 为准；
   • 没有暂存变更时，查看 git diff，并在需要时检查相关未跟踪文件；
   • 仅要求生成或检查消息时，不修改暂存区，不执行 git commit。
3. 判断主要变更意图，选择唯一的 type，再编写标题；仅在标题不足以说明变更时添加正文。
4. 用户明确要求执行提交时：
   • 提交已有暂存变更；
   • 用户明确指定提交范围时，可以使用 git add 暂存该范围；
   • 暂存区为空时，若提交范围可由当前任务上下文明确推断（如本会话刚完成的全部变更），视为范围明确，可自行暂存；无法推断时先向用户确认，不要自行暂存全部变更；
   • 使用生成并校验后的消息执行 git commit，完成后检查最新提交和工作区状态；
   • 除非用户明确要求，否则不执行 git commit --amend，不使用 --no-verify 跳过 hooks；
   • 仅在用户明确要求时执行 git push，并遵守全局 Git 策略：禁止 --force/-f；默认禁止向 master 或 main 分支推送，但用户明确授权该分支（如指定“提交到 main”、“直接 push main”）时按指示执行并记录。
5. 输出前逐项检查格式、语言、长度和标点。

Type 选择

type 只能从以下值中选择：

• build：依赖升级、构建脚本、构建配置等维护性变更；
• ci：持续集成、流水线及其配置变更；
• docs：仅文档变更；
• feat：新增用户可感知的功能；
• fix：修复缺陷；
• perf：性能优化；
• refactor：不改变外部行为的代码重构，或其他无法归类的维护性变更；
• style：仅代码格式、排版等不影响逻辑的变更；
• test：新增或调整测试。

依赖升级、构建脚本、配置等维护类提交优先使用 build 或 ci；无法归类时使用 refactor。回滚提交不使用额外类型，应按回滚产生的实际影响选择上述 type。

输出规范

• 标题格式必须为 type: 中文描述。
• 描述使用简体中文，简洁明确，推荐不超过 50 个字符。
• 正文可选；标题足以说明变更时省略正文。
• 正文必须使用两个空格缩进的编号列表，保留 1.、2.、3. 等序号。
• 正文单行尽量不超过 72 个字符；内容过长时主动换行，续行与正文内容对齐。
• 统一使用中文标点。
• 仅生成或检查消息时，只输出 commit message 纯文本，不附加解释，不使用 Markdown 标题、代码块或引用。
• 执行提交后，简洁报告提交成功，并给出提交哈希和实际使用的 commit message；失败时说明错误且不要推送。

示例

仅标题：

docs: 补充部署配置说明

包含正文：

fix: 修复 UpdateConfig 内部版本号不一致问题

  1. UpdateConfig 现在会将配置内容里的 configVersion 覆盖为后端格式化后的版本号，
     与 AddConfigV2 的处理保持一致，避免多个存储层的版本号不一致；
  2. 修复更新 OSS 内容序列化失败后未立即返回的问题。

输出前检查

• type 是否属于允许列表，并准确表达主要变更意图；
• 标题是否为简体中文且无需正文就能概括主要变更；
• 正文是否确有必要，是否使用两个空格缩进的编号列表；
• 长行是否合理换行，标点是否统一为中文标点；
• 用户是否仅要求生成消息；如果是，输出中是否只有 commit message 本身；
• 如果执行提交，提交范围是否明确，提交结果是否已经验证；
• 若执行过 git push，是否仅在用户明确要求且满足全局策略（无 --force/-f；默认非 master/main 分支，或用户已明确授权该分支）时执行。