用途：在提交代码变更、暂存文件或撰写提交信息时，帮助生成干净、原子化的提交，每次提交只对应一个逻辑变更，并遵循项目自身的提交约定。
主要能力：
- 提交格式：若 CLAUDE.md 的 ## Commit conventions 中定义了格式则优先使用；否则采用 conventional commits，格式为 <type>(<scope>): <short description>，可带说明原因的正文和引用工单的页脚。类型包括 feat、fix、ref、docs、test、chore。标题不超过 50 字符，使用祈使语气，聚焦“为什么”而非“是什么”，必要时引用工单（如 Refs PROJ-1234）。
- 安全检查：暂存前检查潜在密钥。需拦截的文件模式包括 .env、.env.、credentials.、secrets.、key.pem、*.p12；需检测的内容模式包括 API_KEY=、SECRET_KEY=、PASSWORD=、TOKEN=、-----BEGIN (RSA |EC |OPENSSH )?PRIVATE KEY-----、AWS 访问密钥（AKIA...）、GitHub 令牌（ghp...、gho_...）、Stripe 密钥（sk_live_...）、内嵌密码的数据库连接串，以及看起来像凭据的高熵字符串。发现潜在密钥时：不要暂存该文件，说明检测到什么及风险，建议将文件或模式加入 .gitignore，并询问开发者如何处理。
使用方式（流程）：
- 审查变更：运行 git status 查看所有变更文件，运行 git diff 查看已暂存和未暂存的变更，理解改了什么及原因；若变更涉及多个不相关事项，询问开发者是否应拆分为多个提交。
- 暂存文件：使用 git add <specific files>，绝不用 git add .；按逻辑变更分组；每个文件暂存前执行安全检查；若涉及多个逻辑单元则拆分为多个提交。
- 起草提交信息：遵循上述提交格式，必要时引用工单，正文保持简洁。
- 与开发者确认：展示暂存文件和拟定的提交信息，等待批准后再执行，未经确认绝不提交。
- 执行并验证：创建提交，运行 git log -1 确认提交已创建，运行 git status 验证工作区干净。
关键原则：原子化，每次提交一个逻辑变更；绝不提交密钥；提交信息中不出现 AI 引用；先确认再提交；信息解释原因；项目约定优先。
限制：资料未提供该技能的安装方式、支持平台、收费情况或具体实现细节。