用途
commit 用于根据当前变更生成高质量的约定式提交消息，并按用户要求完成本地提交。
核心目标是用一条准确、简洁、可追溯的消息说清本次变更。
触发场景
当用户说「提交」「commit」「git commit」「帮我提交」「写个提交消息」，或要求审查提交消息时使用。
主要能力
消息格式
使用以下格式生成提交消息：
<type>[(scope)]: <summary>
[body]
[footer]
类型选择
选择最贴近变更目的的类型：
- feat：新功能
- fix：缺陷修复
- refactor：重构
- perf：性能优化
- docs：文档
- test：测试
- build：构建或依赖
- ci：持续集成
- style：不影响逻辑的格式调整
- chore：其他维护
- revert：回退提交
scope
scope 仅在能稳定指向模块、组件或业务领域时使用；无法准确归类时省略。
summary
summary 使用祈使语气，直接描述变更带来的结果；不加句号，标题不超过 72 个字符。沿用用户和代码中已确定的术语，不臆造命名。
body 与 footer
只有标题无法说清变更内容或原因时才添加 body；说明「改了什么、为什么改」，不复述代码实现细节。
破坏性变更在类型后加 !，并在 footer 中写明 BREAKING CHANGE: <影响>。关联信息按需使用 Refs: #123。
一条消息只表达一个逻辑变更。变更包含多个独立目的时，应拆分提交。
使用方式
流程
优先根据当前会话理解变更目的和范围。信息不足时，只读取判断消息所需的 git status 和相关 diff，不得为重新理解已知改动而扩大调查。
提交消息涉及业务术语时，优先使用当前会话已知的统一术语。
执行边界
- 用户只要求「写提交消息」或「审查消息」时，只输出结果，不执行 Git 写入。
- 用户要求「提交」时，只暂存当前会话相关的改动。如果已暂存内容的归属不清，在写入前使用提问工具确认。
- 不得自动 push。
示例
fix(订单): 处理空订单号时不再崩溃
feat(api)!: 使用信封格式包装审批响应
统一响应元数据的承载方式。
BREAKING CHANGE: 客户端必须从 data 字段读取原响应内容
适用场景
适用于需要生成规范化 Git 提交消息、按约定式提交规范整理变更记录、以及按用户要求完成本地提交的日常开发场景。
限制
只暂存当前会话相关的改动，不自动 push。其余细节暂未提供。