用途：在仓库中准备、拆分、审查或创建 Git 提交时使用，尤其适合较大实现需要拆分为多个提交的场景。
主要能力与规范： 提交信息模板为 <type>(<scope>): <subject> 加正文。type 可取 agents、chore、ci、docs、feat、fix、perf、refactor、test、tool；scope 可为项目、包或应用名，没有明确 scope 时可省略括号部分。subject 与正文首段用平实具体的语言写，让不了解内部实现的同事也能看懂，术语和实现细节放到后文。除真正机械或琐碎的改动外，每次提交都应带正文说明。每行不超过 72 字符，正文需硬换行到 72 列。使用祈使语气，简洁表达；用户提供的上下文若能改善信息可纳入；不得加入 AI 署名；不要叙述自身流程或验证过程，省略测试结果、通过数量和“已用……验证”之类说明。
写正文：对 fix 或 feat，先写流程再解释代码——先用平实语言描述具体情境（bug 的复现步骤与错误行为，或功能中用户能做什么、能看到什么），再写原因与改动（哪里错或缺失、本次提交如何修复）。refactor 或依赖升级等没有流程的改动可跳过第一段。
提交边界：每个提交应可独立理解、可独立发布。无关行为、不同包区域、生成产物和依赖升级要拆成独立提交。较大实现按垂直切片提交，测试或夹具、实现、文档示例、后续打磨可分开，前提是每个提交本身仍成立。不要混合机械格式化与行为改动，除非格式化只触及该改动所需文件。不要包含来自 .agents/ignore/、.context/、日志、构建输出或编辑器文件的本地产物。提交前用 git diff --cached 检查暂存内容，确认每个文件都属于该提交声称的目的。若两项改动需要不同测试命令或不同审查者，通常应拆为不同提交。
每次提交前验证：每个提交创建前都要验证，验证内容不写进提交信息；状态、测试输出、通过数量放在交接说明中。若完整基线因无关的既有问题失败，应在交接中说明并给出第一个相关失败；除非所需命令实际通过，否则不得称该提交已完整验证。
创建提交：尽量使用非交互命令，如 git status --short、git diff -- <paths>、git add <paths>、git diff --cached、git commit -m "<message>"。普通源码改动应带换行的提交正文，可用 git commit -F - <<'COMMIT' ... COMMIT 形式；仅当没有有用描述（如错别字修复或纯机械格式化）时才使用只有 subject 的提交。
限制：资料未提供该技能的安装方式、收费、支持平台或其他集成信息。