用途：帮助把工作区改动拆分为可审阅的逻辑单元，按 Conventional Commits 规范提交，形成清晰的仓库历史。
工作流程：先查看最近提交以匹配仓库风格（git log --oneline -10）；再检查工作区状态与差异（git status、git diff、git diff --staged），注意不要使用 -uall 标志，以免在大型仓库中引发内存问题。
暂存：只暂存属于当前逻辑变更的文件，不要盲目执行 git add -A 或 git add .，应指定目标文件或目录（git add <target-files-or-directories>）。暂存后必须用 git diff --staged 查看将被提交的确切内容，因为 git diff 不显示新增未跟踪文件和全部已暂存改动。禁止包含 .env 或含凭据的文件；如用户明确要求提交此类文件，应停止并要求先移除或脱敏。用户明确排除的文件也不要包含。若一组暂存内容包含多个逻辑上独立的改动，应拆分为多次提交。
提交信息：采用 Conventional Commits 格式 type(scope): description，type 可用 feat、fix、docs、style、refactor、test、chore、ci、perf、build 等；scope 可选；描述用英文、祈使语气（如 add 而非 added），强调改动原因。不要包含共同作者行或“Claude Code”“Codex”等代理名称。示例命令：git commit -m "$(cat <<'EOF' <type>(<scope>): <description>
<body-if-needed> EOF )"。
验证：提交后需核对实际提交内容，因为提交钩子或格式化工具可能修改并重新暂存文件。使用 git log --oneline -5、git show --stat HEAD、git show HEAD 和 git status 检查钩子产生的改动是否已包含在提交中或遗留未提交；如有问题用后续提交处理。
限制与注意事项：若提交前钩子失败则未创建提交，应修复问题后新建提交，不要用 --amend；不要用 --no-verify 绕过钩子，应排查并修复失败原因；推送不在本技能范围内，除非用户明确要求，否则不要推送。