yy-commit
此技能帮助用户创建高质量的 Git 提交，生成规范的中文提交信息。
工作流程
按照以下步骤执行提交流程：
1. 分析当前状态
首先，并行运行以下命令了解当前状态：
git status
git diff
git diff --staged
git log --oneline -5这些命令帮助你理解：
- 哪些文件已修改
- 变更的具体内容
- 是否有已暂存的内容
- 项目的提交历史风格
2. 理解改动意图
综合以下信息理解此次提交的目的和原因：
- 代码变更分析：从 diff 中识别：
- 新增了什么功能？ - 修复了什么问题？ - 优化或重构了什么？ - 更新了什么文档？
- 对话上下文：如果当前对话中有相关讨论，提取：
- 用户想要实现的功能 - 用户提到的问题或需求 - 之前讨论的改动意图 - 用户为什么要做这个改动？解决什么痛点？
- 变更范围：确定影响的模块或功能区域
- 深层理解：
- 不仅仅理解"做了什么"，更要理解"为什么要这么做" - 这是解决了什么问题？避免了什么冲突？ - 这是为了支持什么新功能或改进什么体验？
3. 智能选择暂存文件
根据以下原则选择需要暂存的文件：
应该暂存的文件：
- 源代码文件（.ts,.js,.vue,.jsx,.tsx 等）
- 配置文件（package.json, tsconfig.json 等）
- 文档文件（.md,.txt 等）
- 样式文件（.css,.scss 等）
- 测试文件
应该警告的文件（询问用户）：
- 环境变量文件（.env,.env.local 等）
- 凭证文件（credentials.json, secrets.* 等）
- 私钥文件（*.key,*.pem 等）
- 大型二进制文件
- node_modules 或其他依赖目录
应该忽略的文件：
- 构建产物（dist/, build/ 等，除非明确需要）
- 临时文件（*.tmp,*.swp 等）
如果发现需要警告的文件，明确告知用户并询问是否应该包含。
4. 生成提交信息
默认情况下，提交信息必须遵循 Conventional Commits 规范：type(scope): description
参考链接：
如果用户项目根目录下的 AGENTS.md、README 或其他明确规则中定义了不同的 Git 提交规范，则以用户项目自己的约定为准。只有在没有额外约束时，才使用 Conventional Commits 规范生成提交信息。
Type（类型）：
feat- 新功能fix- 修复 bugdocs- 文档更新style- 代码格式调整（不影响功能）refactor- 重构（既非新功能也非修复）perf- 性能优化test- 测试相关chore- 构建/工具/依赖相关revert- 回滚提交
Scope（范围）- 可选：
- 受影响的模块、组件或功能区域
- 优先使用具体的组件/模块名称，而不是泛化的类型名称
- ✅ DialogInstallationOptions（具体组件名） - ❌ dialog（泛化类型） - ✅ useAuth（具体 composable 名） - ❌ hooks（泛化类型）
- 例如：
auth、DialogConfirmClose、useDialogConfirmClose
Description（描述）：
- 使用中文（代码标识符、专有名词除外）
- 使用动词开头的祈使语气
- 精炼，不超过 50 个字符，一句话。
- 重要原则：优先说明"为什么"或"为了解决什么问题"，而不只是"做了什么"
- 精确性原则：当改动内容不多时，提交信息不应过于宽泛，要具体描述变更的细节
- 例如：不说"更新 Vue 技能名称和安装命令"，而说"更新 Vue 技能为 vue-best-practices 并添加安装命令"
- 避免使用"统一"、"所有"等绝对性词汇：基于实际修改的文件来描述
- 少量文件（3-5个以内）：列出具体名称 - 多量文件：用"多个"、"X个"等描述 - 例如：不说"统一弹窗组件样式"，而说"调整 DialogFeedback 和 PanelCards 组件样式" - 说明：这么做是因为要判断“统一”、“所有”的正确性可能需要读取大量文件内容到AI上下文中，会影响性能
- 如果有对话上下文，必须结合上下文说明改动的目的
- 例如：不说"重命名 plan/spec 技能"，而说"重命名 plan/spec 技能避免与 trae 编辑器命令冲突"
示例：
优秀的提交信息：
feat(auth): 添加 JWT 用户认证功能
fix(editor): 修复文件保存时的编码错误
docs(readme): 更新安装说明和环境要求
refactor(api): 简化请求拦截器逻辑
refactor: 重命名 plan/spec 技能避免与 trae 编辑器命令冲突需要改进的提交信息：
❌ 更新代码 （太模糊）
❌ fix bug （未使用中文，不够具体）
❌ docs(readme): 更新 Vue 技能名称和安装命令 （过于宽泛，不够具体）
❌ refactor: 重命名 plan/spec 技能 （只说了做了什么，没说为什么）
❌ feat(build): 添加 SKILL.md 格式验证脚本 （只说添加脚本，但没说为什么要这么做）
❌ feat: 添加了一个新的用户登录功能并且优化了登录页面的 UI （太长，包含多个改动）
❌ style(mobile): 统一弹窗组件样式单位为 rem （只修改了部分弹窗组件，但用了"统一"）更好的版本：
✅ docs(readme): 更新 Vue 技能为 vue-best-practices 并添加安装命令
✅ refactor: 重命名 plan/spec 技能避免与 trae 编辑器命令冲突
✅ style(mobile): 调整 DialogFeedback 和 PanelCards 组件字体为 rem 并增大基础字体为 20px5. 展示并确认
在执行提交前，向用户展示：
- 将要暂存的文件列表
- 关键变更摘要（从 diff 提取的主要改动）
- 生成的提交信息
重要提示： 用户可能会对提交信息提出修改意见（例如认为信息过于宽泛、不够具体等），应该认真听取用户反馈并调整提交信息，直到用户满意为止，禁止绕过用户确认步骤直接提交。
使用清晰的格式展示，例如：
即将提交以下更改：
📝 暂存文件：
- src/auth/login.ts
- src/components/LoginForm.vue
- docs/api.md
📊 主要变更：
- 新增 JWT token 生成逻辑
- 添加登录表单验证
- 更新 API 文档
💬 提交信息：
feat(auth): 添加 JWT 用户认证功能
是否确认提交？处理用户反馈：
如果用户反馈"scope 太宽泛"、"描述不够具体"等意见：
- 认真听取用户反馈
- 根据反馈调整提交信息
- 再次展示并询问确认
- 重复此过程直到用户满意并确认提交
6. 执行提交
用户确认后，按顺序执行（不可并行执行）：
# 1. 暂存选定的文件（一次一个或使用 git add -A 如果全部暂存）
git add <file1> <file2> ...
# 2. 创建提交
git commit -m "<提交信息>"特殊情况处理
多个独立改动
如果发现多个不相关的改动（例如既有新功能又有 bug 修复），建议用户分别提交：
我注意到此次变更包含两个独立的改动：
1. 新增用户认证功能
2. 修复编辑器保存 bug
建议分别提交以保持提交历史清晰。我可以帮你：
a) 先提交认证功能
b) 再提交 bug 修复
你希望如何处理？无变更内容
如果 git status 显示没有变更，告知用户：
当前工作区没有未提交的变更。
如果你期望有变更，可能的原因：
- 文件尚未保存
- 变更已经在之前的提交中
- .gitignore 忽略了这些文件冲突或未推送的提交
如果发现有未推送的提交或合并冲突，提醒用户：
⚠️ 注意：
- 有 X 个提交尚未推送到远程仓库
- 建议在继续前先推送或解决冲突注意事项
- 从不跳过 hook：不使用
--no-verify等标志 - 不强制操作：不使用
--force或--amend（除非用户明确要求） - 保护主分支：如果在 main/master 分支，提醒用户考虑在功能分支工作
- 尊重.gitignore：不提交被忽略的文件
- 保持原子性：每次提交应该是一个逻辑单元
最佳实践
- 提交信息应该回答"这个提交做了什么，以及为什么要这么做"
- 优先说明改动的目的/原因，而不只是描述改动本身
- 保持提交信息的精确性：小改动要有具体的描述，避免过于宽泛
- 即使只修改了一个小细节，也要具体说明改了什么 - 例如："更新 Vue 技能为 vue-best-practices 并添加安装命令" 比 "更新文档" 更好
- 认真对待用户反馈：如果用户认为提交信息不够好，立即调整优化
- 优先使用对话上下文理解真实意图
- 当不确定变更意图时，询问用户
- 保持提交小而聚焦
- 使用有意义的 scope 帮助快速定位
- 提交信息涉及具体文件名时，必须保留原文件名，不得翻译