提交信息生成器

工作流程

运行 git diff --staged 检查暂存区变更。如果为空，请告知用户先运行 git add 并停止。
根据下面的语言策略确定描述语言。
生成一条或多条信息并显示供确认；不要立即提交。当存在多个合理的表述框架时，将它们以简短的编号列表（1)、2)、…）形式呈现，用户只需回复编号即可选择。如果是单一清晰的信息，可以单独显示。用户也可以回复编辑版本或自己的措辞。
仅当用户选择或明确确认后（从列表中选择编号、回复“commit”或“ok”均可），才运行 git commit -m。除非用户明确要求，否则不要运行 git push。

对于 type(scope): 之后的人类可读描述，请按以下优先级使用：

按上述顺序严格执行，并在第一个匹配项处停止。在第4项之前检查第2和第3项。单独的斜杠命令或技能调用没有语言；继续执行第5项。最多检查最近20个主题。

保持 Conventional Commits 语法令牌不翻译：type、可选的 scope、! 和 BREAKING CHANGE。保持标识符、文件名、包名、命令、API 名称和作用域使用原始语言。

在常规提交生成过程中不要写入配置。如果用户明确要求记住提交描述语言，请提供持久化选项。当范围不明确时，询问是仓库级别还是全局级别。

对于仓库偏好，创建或更新 .agent-tools/config.jsonc；对于全局偏好，使用 ~/.agent-tools/config.jsonc：

{
  "at-commit.language": "zh-CN"
}

尽可能保留不相关的键和注释。无需事先安装设置。

读取 git diff --staged 并生成一条 Conventional Commits 标题，说明变更内容（WHAT）以及在有用时说明原因（WHY）。

标题：type(scope): description，不超过74个字符，末尾无句点，无前缀，无引号，无代码块。
type：从以下类型中仅选择一个：
- feat 表示新功能，fix 表示缺陷修复
- refactor 表示保持行为不变的重构，perf 表示性能优化
- docs 表示仅文档变更，style 表示仅格式变更
- test 表示添加或修复测试，build 表示构建系统或依赖项，ci 表示 CI 配置/脚本
- chore 表示不涉及 src/test 的其他杂项变更，revert 表示回滚
scope：可选的影响模块名称。使用此仓库的惯例。在单仓（monorepo）中，使用应用/包目录名。对于跨领域变更或不确定时，省略此项。
description：一个简洁的动词-宾语短语，使用选定的自然语言。避免使用诸如“更新文件”、“此提交”、“杂项变更”或“若干变更”之类的填充词。保留标识符、函数名、文件名、包名、命令和 API 的原文。
仅单行：提交信息始终只包含标题行。不要写正文或页脚。将必要的 WHY 压缩到标题中。
破坏性变更：使用 type(scope)!: description 标记，仍为单行。不要使用 BREAKING CHANGE 页脚。
标点符号：使用 ASCII 标点符号。

在编写之前，识别暂存区变更的脉络主线。

信息必须陈述已确认的代码事实，而非猜测的意图。

优先关注 src 和 test 中的行为变更：文档仅作为支持性上下文。不要仅根据文档推断 WHAT。
用户上下文优于文档：明确的用户目标有助于选择 WHY 和措辞，但 WHAT 和作用域仍来自暂存区差异比较。如果上下文和差异比较冲突，遵循差异比较并请求确认。
删除和重命名：当无法从代码关系中确认目的时，仅陈述差异比较证明的内容，例如“删除 X”或“将 X 重命名为 Y”。除非代码证明，否则不要声称替换、迁移或因果关系。
具有同一目标的多个变更：当变更明显服务于同一目标时（例如质量或构建修复），提供一条汇总信息。仅当拆分能够显著改善审查或回滚时才建议拆分。
无关的暂存区变更：为每个连贯的单元提供拆分信息，外加一条保守的汇总信息。让用户选择拆分还是汇总，而不是将汇总推迟到下一轮。
所有权或意图不明确：列出需要确认的文件，而不是强制使用模糊的信息。当意图不明确时，优先确认或拆分，而不是使用“更新”、“调整”或“微调”等模糊词汇。