用途 该技能用于创建标准化、语义化的 git 提交，遵循 Conventional Commits 规范。它会分析实际的 diff 内容，以确定合适的提交类型、作用域和提交信息。当用户要求提交改动、创建 git 提交时使用。
提交信息格式 <type>[optional scope]: <description>
[optional body]
[optional footer(s)]
提交类型
- feat：新功能
- fix：缺陷修复
- docs：仅文档
- style：格式/样式（不涉及逻辑）
- refactor：代码重构（既非新功能也非修复）
- perf：性能改进
- test：新增/更新测试
- build：构建系统/依赖
- ci：CI/配置变更
- chore：维护/杂项
- revert：回滚提交
破坏性变更
可用类型/作用域后的感叹号表示，例如 feat!: remove deprecated endpoint；也可用 BREAKING CHANGE 页脚，例如：feat: allow config to extend other configs，随后 BREAKING CHANGE: extends key behavior changed。
工作流程
- 分析 diff：若已有暂存内容，使用 git diff --staged；若未暂存，使用 git diff；同时检查状态 git status --porcelain。
- 暂存文件（如需要）：若没有暂存内容或想按不同方式分组改动，可暂存指定文件（git add path/to/file1 path/to/file2）、按模式暂存（git add .test.、git add src/components/*）或交互式暂存（git add -p）。切勿提交机密信息（.env、credentials.json、私钥）。
- 生成提交信息：分析 diff 以确定类型（这是何种变更）、作用域（受影响的区域/模块）、描述（一行变更摘要，使用现在时、祈使语气，少于 72 字符）。
- 执行提交：单行可用 git commit -m "<type>[scope]: <description>"；多行含正文/页脚可用 git commit -m "$(cat <<'EOF' ... EOF)" 形式。
最佳实践 每次提交只包含一个逻辑变更；使用现在时（add 而非 added）；使用祈使语气（fix bug 而非 fixes bug）；引用议题（Closes #123、Refs #456）；描述保持在 72 字符以内。
Git 安全协议 绝不更新 git config；未经明确请求绝不运行破坏性命令（--force、hard reset）；除非用户要求，绝不跳过钩子（--no-verify）；绝不向 main/master 强制推送；若因钩子导致提交失败，修复后创建新的提交（不要 amend）。
适用场景 适用于需要在提交时自动判定语义化类型与作用域、生成规范提交信息的日常开发流程。
限制 暂未提供除上述范围外的功能、收费、价格、平台或效果等信息。