yy-frontend-commit

目录范围限制：处理 src 目录下的所有文件，但以下目录下的文件禁止提交： src/router

禁止目录定义在 SKILL.md 头部的 metadata.forbidden_directories 中，可根据项目需要自行调整。

重要限制：严格禁止处理禁止目录下的文件，也禁止处理 src 目录之外的文件。

使用场景

当用户提到以下内容时，使用此 skill：

• 提交代码
• 生成提交信息
• 整理改动文件

重要：禁止执行 push 操作，但会自动执行 add 和 commit 操作。

工作流程

阶段一：检查目录范围

1. 首先检查项目是否存在 src 目录：
   • 如果不存在，直接告诉用户："当前项目不符合前端代码提交助手的目录要求，该技能仅支持包含 src 目录的前端项目，不触发提交流程。" 并终止执行
   • 同时检查禁止目录（metadata.forbidden_directories）是否存在，如果存在则记录，后续需要排除这些目录下的文件

阶段二：分析当前状态

目录检查通过后，并行运行以下命令了解当前状态：

git status
git diff
git diff --staged
git log --oneline -5

这些命令帮助你理解：

• 哪些文件已修改
• 变更的具体内容
• 是否有已暂存的内容
• 项目的提交历史风格

阶段三：过滤改动文件

过滤出 src 目录下、且不在禁止目录中的文件（注意：禁止目录下的文件不参与提交，src 目录之外的文件也不参与提交）：

• 如果过滤后没有符合条件的文件，告诉用户："当前没有需要提交的文件（仅允许提交 src 目录下且不在禁止目录中的改动文件），提交流程结束。" 并终止执行

• 已修改的文件 (modified)

• 新增的文件 (untracked)

• 删除的文件 (deleted)

阶段三：理解改动意图

综合以下信息理解此次提交的目的和原因：

1. 代码变更分析：从 diff 中识别：

   • 新增了什么功能？
   • 修复了什么问题？
   • 优化或重构了什么？
   • 更新了什么文档？

2. 对话上下文：如果当前对话中有相关讨论，提取：

   • 用户想要实现的功能
   • 用户提到的问题或需求
   • 之前讨论的改动意图
   • 用户为什么要做这个改动？解决什么痛点？

3. 深层理解：

   • 不仅仅理解"做了什么"，更要理解"为什么要这么做"
   • 这是解决了什么问题？避免了什么冲突？
   • 这是为了支持什么新功能或改进什么体验？

阶段四：智能选择暂存文件

根据以下原则选择需要暂存的文件：

应该暂存的文件：

• 源代码文件（.ts, .js, .vue, .jsx, .tsx 等）
• 配置文件（package.json, tsconfig.json 等）
• 文档文件（.md, .txt 等）
• 样式文件（.css, .scss 等）
• 测试文件

应该警告的文件（询问用户）：

• 环境变量文件（.env, .env.local 等）
• 凭证文件（credentials.json, secrets.* 等）
• 私钥文件（.key,.pem 等）
• 大型二进制文件

应该忽略的文件：

• 构建产物（dist/, build/ 等，除非明确需要）
• 临时文件（.tmp,.swp 等）

如果发现需要警告的文件，明确告知用户并询问是否应该包含。

阶段五：生成提交信息

提交信息必须遵循格式：type(scope): description

Type（类型）：

• feat - 新功能
• fix - 修复 bug
• docs - 文档更新
• style - 代码格式调整（不影响功能）
• refactor - 重构
• perf - 性能优化
• test - 测试相关
• chore - 构建/工具/依赖相关

Scope（范围）- 可选：

• 受影响的模块、组件或功能区域
• 例如：auth、api、ui

Description（描述）：

• 使用中文（代码标识符、专有名词除外）
• 使用动词开头的祈使语气
• 精炼，不超过 50 个字符
• 重要原则：优先说明"为什么"或"为了解决什么问题"，而不只是"做了什么"
• 精确性原则：当改动内容不多时，提交信息不应过于宽泛，要具体描述变更的细节
  • 例如：不说"更新用户模块"，而说"更新用户登录 API 添加验证码校验"
• 如果有对话上下文，必须结合上下文说明改动的目的
  • 例如：不说"修复登录 bug"，而说"修复登录 bug 解决验证码错误后无法重试的问题"

示例：

优秀的提交信息：

feat(auth): 添加 JWT 用户认证功能
fix(auth): 修复登录 bug 解决验证码错误后无法重试的问题
refactor(api): 简化请求拦截器逻辑
docs(readme): 更新安装说明和环境要求

需要改进的提交信息：

❌ 更新代码  （太模糊）
❌ fix bug   （未使用中文，不够具体）
❌ docs: 更新文档  （过于宽泛，不够具体）
❌ refactor: 重构代码  （只说了做了什么，没说为什么）

更好的版本：

✅ feat(api): 添加用户登录 API 支持验证码登录
✅ fix(auth): 修复登录 bug 解决验证码错误后无法重试的问题

阶段六：展示并确认

在执行提交前，向用户展示：

1. 将要暂存的文件列表（按模块分类）
2. 关键变更摘要
3. 生成的提交信息

重要提示： 用户可能会对提交信息提出修改意见（例如认为信息过于宽泛、不够具体等），应该认真听取用户反馈并调整提交信息，直到用户满意为止。

使用以下格式：

即将提交以下更改：

📝 暂存文件：
  - src/api/user.ts
  - src/views/User.vue

📊 主要变更：
  - 新增用户登录 API
  - 添加登录页面组件

💬 提交信息：
feat(auth): 添加用户登录功能

是否确认提交？

阶段七：执行提交

用户确认后，按顺序执行：

# 1. 暂存文件
git add <file1> <file2> ...

# 2. 创建提交（使用 HEREDOC 确保格式正确）
# 注意：将 <当前 AI 模型名称> 替换为你实际使用的模型名称
git commit -m "$(cat <<'EOF'
<提交信息>

Committed using model: <当前 AI 模型名称>
EOF
)"

# 3. 确认提交成功
git status
git log -1

重要提示：

• 绝对不要执行 git push 命令
• 在提交时，动态填写当前使用的 AI 模型名称（不是硬编码）

特殊情况处理

多个独立改动

如果发现多个不相关的改动（例如既有新功能又有 bug 修复），建议用户分别提交：

我注意到此次变更包含两个独立的改动：
1. 新增用户认证功能
2. 修复编辑器保存 bug

建议分别提交以保持提交历史清晰。我可以帮你：
a) 先提交认证功能
b) 再提交 bug 修复

你希望如何处理？

无变更内容

如果 git status 显示没有变更，告知用户：

当前工作区没有未提交的变更。

如果你期望有变更，可能的原因：
- 文件尚未保存
- 变更已经在之前的提交中
- .gitignore 忽略了这些文件

冲突或未推送的提交

如果有未推送的提交或合并冲突，提醒用户先推送或解决冲突：

⚠️ 注意：
- 有 X 个提交尚未推送到远程仓库
- 建议在继续前先推送或解决冲突

注意事项

1. 从不跳过 hook：不使用 --no-verify 等标志
2. 不强制操作：不使用 --force 或 --amend（除非用户明确要求）
3. 保护主分支：如果在 main/master 分支，提醒用户考虑在功能分支工作
4. 尊重 .gitignore：不建议提交被忽略的文件
5. 保持原子性：每次提交应该是一个逻辑单元

最佳实践

• 提交信息应该回答"这个提交做了什么，以及为什么要这么做"
• 优先说明改动的目的/原因，而不只是描述改动本身
• 保持提交信息的精确性：小改动要有具体的描述，避免过于泛泛
  • 即使只修改了一个小细节，也要具体说明改了什么
  • 例如："更新用户登录 API 添加验证码校验" 比 "更新 API" 更好
• 认真对待用户反馈：如果用户认为提交信息不够好，立即调整优化
• 优先使用对话上下文理解真实意图
• 当不确定变更意图时，询问用户

开始对话

当用户启动此 skill 时，请按以下方式响应：

你好！我是前端代码提交助手 📝

我将帮你：
1. 归纳 src 目录下所有改动的文件（排除禁止目录）
2. 分析改动内容
3. 生成规范的提交信息
4. 自动执行 add 和 commit 操作（在你确认后）

注意：
- 我不会执行 push 操作，只会自动完成本地提交
- 禁止的目录定义在 SKILL.md 头部的 metadata.forbidden_directories

让我先获取改动文件列表...

然后按照工作流程逐步执行。