commit-convention

Commit Convention 是一个专注于 Git 提交信息规范化的技能，着重于提交信息的格式化与风格统一。它不直接执行 git commit 或 git add 操作，而是为当前 Agent 提供提交信息的决策指导和格式标准。

用途 该技能用于在生成 Git 提交信息时提供统一的决策逻辑和格式规范，帮助 Agent 产出风格一致、符合项目习惯的提交信息。

主要能力

1. 风格学习（优先）：在生成提交信息前，先观察项目已有的提交习惯。执行 git log -n 5 --oneline 查看历史记录。如果项目习惯使用特定前缀（如 [FEAT]、Update: 等）或语言习惯，应优先模仿并保持一致。语言一致性方面，如果历史记录全是中文，则使用中文描述；如果全是英文，则使用英文。
2. 规范回退（Fallback）：如果项目提交记录为空、无明显规律，或项目明确要求使用规范化提交，则遵循 Conventional Commits 规范，格式为 <type>(<scope>): <subject>，可附带 <body>。

Type 类型定义

• feat：新功能
• fix：修补 bug
• docs：文档变更
• style：不影响代码含义的变更（空白、格式、缺少分号等）
• refactor：重构（既不是修复 bug 也不是添加特征的代码更改）
• perf：改进性能
• test：添加缺失测试或更正现有测试
• build：影响构建系统或外部依赖项的更改
• ci：更改 CI 配置文件和脚本
• chore：其他不修改 src 或测试文件的更改
• revert：回退之前的提交

Subject 格式

• 使用祈使句（如 "add" 而不是 "added"）
• 结尾不加句号
• 首字母小写（除非是专有名词）
• 长度控制在 50 字符以内

使用方式 当 Agent 需要生成提交信息时，按以下逻辑思考：

1. 观察：使用 git log -n 5 --oneline 观察项目风格。
2. 判断：发现既定规律则模仿该规律；发现 Conventional Commits 模式则遵循本规范；初始提交或无规律则采用 Conventional Commits。
3. 撰写：编写简洁的 Subject；必要时提供 Body（解释 Why 而不是 How）；关联 Issue（如 Closes #123）。

适用场景 适用于需要为 Git 仓库生成提交信息的场景，尤其是希望保持项目提交历史风格统一、或需要遵循 Conventional Commits 规范的项目。

限制与注意事项

• 严禁过度设计：不要生成过于复杂的提交信息，除非变更确实复杂。
• 原子性：建议一个提交只做一件事。如果发现变更过多，建议提示用户拆分提交。
• 禁止执行命令：本技能仅提供信息建议，执行操作由主 Agent 决定。