Git Committer
这个 skill 帮助分析 git 变更内容并生成符合项目规范的 commit message。
何时使用
当用户出现以下情况时调用此 skill：
-
用户说"提交代码"、"commit"、"生成 commit message"
-
用户需要将当前的代码变更提交到 git 仓库
-
用户想要查看变更并生成提交信息
-
用户执行 git 相关操作时
工作流程
查看 git 状态
-
执行 git status 查看当前变更状态
-
执行 git diff 查看未暂存的变更
-
执行 git diff --cached 查看已暂存的变更
环境配置文件过滤
-
自动识别并过滤环境配置文件的修改
-
常见的环境配置文件包括：
-
vite.config.ts/js
-
webpack.config.js
-
.env 及其变体文件
-
其他构建工具配置文件
-
这些文件的修改不会生成提交计划，直接忽略
分析变更内容
-
识别变更的文件类型和影响范围
-
理解变更的目的和功能
-
确定变更的类型（[feature]、[fix]、[update]、[docs]、[style]、[refactor]、[test]、[chore]、[bump] 等）
判断是否需要拆分提交
-
如果变更涉及多个功能点，必须按功能拆分提交
-
如果变更涉及不同类型的修改（如同时有新功能和 bug 修复），必须拆分提交
-
每个提交应该只做一件事，保持提交的原子性
拆分提交策略
-
按功能模块拆分：将同一功能相关的文件归为一组
-
按变更类型拆分：将新功能、bug 修复、重构等分开提交
-
按文件类型拆分：将代码变更、配置变更、文档变更分开提交
-
每次提交前使用 git add 添加对应的文件，然后提交
生成 commit message
-
遵循项目使用的方括号格式规范
-
格式：type: subject
-
subject 使用中文描述，首字母小写，不以句号结尾
-
包含简洁的描述和必要的详细说明
-
如果有相关 issue，添加引用
-
标题最大宽度 100 字符
用户确认流程
-
必须先展示生成的 commit message 和提交计划，等待用户明确同意后再执行提交
-
只有在用户明确确认后，才能执行 git commit -m "message"
-
绝对禁止在未获得用户明确确认的情况下自动执行 git commit 命令
-
必须在展示 commit message 后等待用户的明确回应，如"确认"、"可以"、"同意"等
-
如果用户对 commit message 提出修改意见，必须根据用户意见调整后重新展示并等待确认
-
如果需要拆分提交，必须为每个提交单独获得用户确认
-
如果用户明确要求合并提交，则以用户为准
执行提交
-
根据用户确认的提交计划执行提交操作
-
使用 git add 选择性添加文件
-
执行 git commit -m "message" 提交变更
-
确保环境配置文件不会被添加到提交中
推送代码（可选）
-
所有提交完成后，询问用户是否需要推送代码
-
如果用户需要推送，调用 push-code skill 来处理推送操作
Commit 类型
-
[feature] : 针对用户的新特性，而不是针对构建脚本的新特性
-
[fix] : 针对用户修复的错误，而不是针对构建脚本的修复
-
[update] : 特性更新、功能优化，而不是新增特性或修复 bug
-
[docs] : 文档修改
-
[style] : 不会影响代码含义的更改（空格，格式，缺少分号等）
-
[refactor] : 重构生产代码，例如重命名变量；既不是修复问题也不是新增功能
-
[test] : 添加缺失的测试用例，重构测试用例；生产代码无变化
-
[chore] : 更新构建工具等；生产代码无变化
-
[bump] : 新版本
示例
单个提交示例
feature: 添加用户登录功能
- 实现登录表单及验证
- 添加 JWT token 处理
- 更新认证状态管理
fix: 解决数据获取超时问题
- 修复连接超时配置
- 添加失败请求重试机制
update: 优化 disabled 模式下的显示逻辑
- 在 disabled 模式下，如果包含或排除没有数据，不展示对应的 group
- 如果包含和排除都没有数据，不展示整个 crowd-rule__content 区域
拆分提交示例
假设同时修改了用户登录功能和修复了 API 超时问题，应该拆分为两个提交：
提交 1：
feature: 添加用户登录功能
- 实现登录表单及验证
- 添加 JWT token 处理
- 更新认证状态管理
提交 2：
fix: 解决数据获取超时问题
- 修复连接超时配置
- 添加失败请求重试机制
假设同时修改了代码和配置文件，应该拆分为两个提交：
提交 1：
refactor: 简化日期格式化逻辑
- 提取通用日期函数
- 提高代码可读性
提交 2：
chore: 切换代理目标到开发环境
- 将代理目标从测试环境切换到开发环境
- 注释掉测试环境 token 配置
注意事项
-
绝对禁止自动执行 git commit，必须获得用户的明确确认
-
必须先展示生成的 commit message，等待用户明确同意后再执行提交
-
如果用户未明确表示同意，任何情况下都不得执行 git commit 命令
-
执行提交前必须再次确认用户的明确意图
-
环境配置的修改（如 vite.config.ts 中的代理配置等）不要自动提交，直接忽略
-
自动识别并过滤常见的环境配置文件，包括但不限于：
-
vite.config.ts/js
-
webpack.config.js
-
.env 及其变体文件
-
其他构建工具配置文件
-
严格区分提交类型，确保使用正确的类型：
-
[feature] ：新功能
-
[fix] ：bug 修复
-
[update] ：功能优化、联调过程中的改进
-
[refactor] ：代码重构
-
[chore] ：构建工具、配置文件修改
-
如果变更复杂，可以提供多个 commit message 选项供用户选择
-
commit message 使用中文描述
-
subject 首字母自动小写，自动移除末尾句号
-
scope 可选，如果提供会自动转换为小写
-
如果有破坏性变更，需要添加 BREAKING CHANGE 说明
-
每个提交应该只做一件事，保持提交的原子性
-
只要涉及多个功能点，就必须按功能拆分提交
-
如果变更涉及不同类型的修改，必须拆分提交
-
拆分提交时，使用 git add 选择性添加文件
-
如果用户明确要求合并提交，则以用户为准
技术实现细节
环境配置文件识别：
-
建立环境配置文件列表，包括常见的构建工具配置文件和环境变量文件
-
在分析变更时，自动过滤这些文件的修改
变更分析：
-
执行 git diff --name-only 获取所有变更文件
-
过滤掉环境配置文件
-
对剩余文件进行分析，确定变更类型和范围
提交计划生成：
-
基于过滤后的变更文件生成提交计划
-
确保环境配置文件的修改不会出现在提交计划中
用户确认流程：
-
展示生成的 commit message 和提交计划
-
等待用户的明确确认
-
只有在用户确认后才执行提交操作
执行提交：
-
使用 git add 选择性添加文件
-
执行 git commit -m "message" 提交变更
-
确保环境配置文件不会被添加到提交中
常见错误处理
用户未确认直接提交：
-
错误：在未获得用户明确确认的情况下执行 git commit 命令
-
处理：必须严格遵守用户确认流程，先展示 commit message，等待用户确认后再执行提交
提交类型选择错误：
-
错误：将联调优化标记为 [fix]，或将 bug 修复标记为 [feature]
-
处理：严格按照提交类型定义选择正确的类型，确保提交信息准确反映变更内容
环境配置文件未过滤：
-
错误：将 vite.config.ts 等环境配置文件的修改包含在提交计划中
-
处理：自动识别并过滤环境配置文件，确保这些修改不会出现在提交计划中
提交拆分不当：
-
错误：将多个功能点或不同类型的修改合并在一个提交中
-
处理：根据功能模块和变更类型拆分提交，保持提交的原子性
用户确认后执行失败：
-
错误：用户确认后执行 git commit 命令失败
-
处理：检查错误信息，根据需要调整提交策略，确保提交成功