用途
该技能用于在提交代码变更、编写提交信息或整理 Git 历史时，生成符合 Conventional Commits 规范的提交信息。其核心理念是：提交信息是写给下一个阅读提交日志的人，而非自己；清晰与一致比简短更重要；提交主题应体现“为什么”提交，而不仅是“改了什么”。
主要能力
- 遵循 Conventional Commits 规范，使用结构化元素表达提交意图。
- 支持多种提交类型：build（构建系统或 CI 变更）、chore（日常维护、依赖更新）、ci（持续集成配置）、docs（文档变更）、feat（新功能）、fix（缺陷修复）、perf（性能改进）、refactor（代码重构，无行为变更）、revert（回滚提交）、style（代码风格与格式）、test（测试新增、更新或改进）。类型来源为 .ai/config.json 中的 git.types。
- 支持作用域（scope，可选）、正文（body）与页脚（footer）。
- 支持 BREAKING CHANGE 标记：在页脚写 BREAKING CHANGE:，或在类型/作用域后加 !，表示引入破坏性 API 变更。
- 提供多种示例，包括简单修复、带作用域的功能、重构、破坏性变更与回滚格式。
使用方式
提交前需确保处于功能分支而非主分支。检查当前分支：
git branch --show-current
若在 main 或 master 上，先创建新分支：
git checkout -b <type>/<short-description>
分支命名遵循 <type>/<short-description>，其中 type 与提交类型一致，例如 feat/add-user-auth、fix/null-pointer-error、refactor/extract-validation。
提交信息格式：
<type>(<scope>): <subject>
<body>
<footer>
头部为必填，作用域可选，所有行不超过 100 字符。
主题行规则：使用祈使句、现在时（如 "add feature" 而非 "added feature"）；始终小写（commitlint 强制小写主题，sentence-case、start-case、pascal-case 均被拒绝）；结尾不加句号；最多 70 字符。
正文指南：解释为何做此决策，而非如何做或做了什么；使用祈使语气与现在时；包含变更动机；相关时对比先前行为；每个独立概念或原因使用一个项目符号（也自然处理行长度）；若某项目符号文本超过 80 字符，在下一行紧贴项目符号文本继续（不缩进）。
适用场景
- 提交代码变更时编写规范提交信息。
- 整理 Git 历史，使提交日志清晰一致。
- 需要与 Semantic Versioning 关联时：fix 对应 PATCH，feat 对应 MINOR，BREAKING CHANGE 对应 MAJOR。
- 需要回滚提交时使用 revert 格式。
限制
- 提交前必须处于功能分支，不能在 main 或 master 上直接提交。
- 主题行必须小写，且不超过 70 字符；所有行不超过 100 字符。
- 提交类型需使用 .ai/config.json 中 git.types 定义的类型。
- 每个提交应为单一、稳定的变更，可独立审查，且提交后仓库应处于可工作状态。
- 其他页脚（除 BREAKING CHANGE: {description} 外）可提供，遵循类似 git trailer 格式的约定。
示例
简单修复（含换行）：
fix(api): handle null response in user endpoint
- the user API could return null for deleted accounts, causing a crash in the dashboard
- add a null check before accessing user properties to prevent the unhandled exception
带作用域的功能（含项目符号）：
feat(alerts): add Slack thread replies for alert updates
- post a reply to the original Slack thread when an alert is updated or resolved instead of creating a new message
- keeps related notifications grouped together for easier scanning
- reduces noise in high-volume alert channels
重构：
refactor: extract common validation logic to shared module
- Move duplicate validation from three endpoints into a shared validator class
- No behavior change
破坏性变更：
feat(api)!: remove deprecated v1 endpoints
- Remove all v1 API endpoints deprecated in version 23.1
- Clients should migrate to v2 endpoints
BREAKING CHANGE: v1 endpoints no longer available
回滚格式：
revert: feat(api): add new endpoint
- Reverts commit abc123def456
- Caused performance regression in production
原则
- 每个提交应为单一、稳定的变更。
- 提交应可独立审查。
- 每次提交后仓库应处于可工作状态。
参考
Conventional Commits Specification