yy-frontend-commit

Directory Scope Restrictions: Processes all files under the

src

directory, but files in the following directories are forbidden to commit:

src/router

Forbidden directories are defined in

metadata.forbidden_directories

at the top of SKILL.md, and can be adjusted according to project needs.

src

Usage Scenarios

• Submit code
• Generate commit messages
• Organize modified files

Workflow

Phase 1: Check Directory Scope

1. First check if the project has an

   src

   directory:
   • If it does not exist, directly tell the user: "The current project does not meet the directory requirements of the Frontend Code Commit Assistant. This skill only supports frontend projects containing an src directory, and the commit process will not be triggered." Then terminate execution
   • At the same time, check if forbidden directories (

     metadata.forbidden_directories

     ) exist, if so, record them, and exclude files under these directories in subsequent steps

Phase 2: Analyze Current Status

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

• Which files have been modified
• Specific content of changes
• Whether there are staged contents
• Commit history style of the project

Phase 3: Filter Modified Files

src

• If there are no eligible files after filtering, tell the user: "There are no files to submit currently (only modified files under the src directory and not in forbidden directories are allowed to be submitted), the commit process ends." Then terminate execution
• Modified files (modified)
• New files (untracked)
• Deleted files (deleted)

Phase 3: Understand Change Intent

1. Code Change Analysis: Identify from the diff:
   • What new features have been added?
   • What bugs have been fixed?
   • What has been optimized or refactored?
   • What documents have been updated?
2. Conversation Context: If there is relevant discussion in the current conversation, extract:
   • Features the user wants to implement
   • Problems or needs mentioned by the user
   • Change intentions discussed previously
   • Why is the user making this change? What pain points does it solve?
3. Deep Understanding:
   • Not only understand "what was done", but also understand "why it was done"
   • What problem does this solve? What conflicts does it avoid?
   • Is this to support new features or improve user experience?

Phase 4: Intelligent Selection of Staged Files

• Source code files (.ts, .js, .vue, .jsx, .tsx, etc.)
• Configuration files (package.json, tsconfig.json, etc.)
• Document files (.md, .txt, etc.)
• Style files (.css, .scss, etc.)
• Test files

• Environment variable files (.env, .env.local, etc.)
• Credential files (credentials.json, secrets.*, etc.)
• Private key files (*.key, *.pem, etc.)
• Large binary files

• Build artifacts (dist/, build/, etc., unless explicitly required)
• Temporary files (*.tmp, *.swp, etc.)

Phase 5: Generate Commit Message

type(scope): description

• feat

  - New feature

• fix

  - Bug fix

• docs

  - Document update

• style

  - Code format adjustment (does not affect functionality)

• refactor

  - Refactoring

• perf

  - Performance optimization

• test

  - Test-related

• chore

  - Build/tool/dependency-related

• Affected modules, components or functional areas
• For example:

  auth

  ,

  api

  ,

  ui

• Use Chinese (except code identifiers and proper nouns)
• Use imperative mood starting with a verb
• Concise, no more than 50 characters
• Important Principle: Prioritize explaining "why" or "what problem is solved", rather than just "what was done"
• Accuracy Principle: When there are not many changes, the commit message should not be too broad, and should specifically describe the details of the change
  • For example: Instead of saying "Update user module", say "Update user login API to add verification code validation"
• If there is conversation context, must combine the context to explain the purpose of the change
  • For example: Instead of saying "Fix login bug", say "Fix login bug to resolve the issue of unable to retry after verification code error"

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

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

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

Phase 6: Display and Confirm

1. List of files to be staged (classified by module)
2. Key change summary
3. Generated commit message

即将提交以下更改：

📝 暂存文件：

- src/api/user.ts
- src/views/User.vue

📊 主要变更：

- 新增用户登录 API
- 添加登录页面组件

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

是否确认提交？

Phase 7: Execute Commit

# 1. Stage files
git add <file1> <file2> ...

# 2. Create commit (use HEREDOC to ensure correct format)
# Note: Replace <Current AI Model Name> with the actual model name you are using
git commit -m "$(cat <<'EOF'
<提交信息>

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

# 3. Confirm commit success
git status
git log -1

• Never execute the git push command
• When committing, dynamically fill in the current AI model name (not hard-coded)

Special Case Handling

Multiple Independent Changes

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

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

你希望如何处理？

No Change Content

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

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

Conflicts or Unpushed Commits

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

Notes

1. Never skip hooks: Do not use flags like

   --no-verify

2. Do not force operations: Do not use

   --force

   or

   --amend

   (unless explicitly requested by the user)
3. Protect main branch: If on main/master branch, remind the user to consider working on a feature branch
4. Respect .gitignore: Do not suggest submitting ignored files
5. Maintain atomicity: Each commit should be a logical unit

Best Practices

• Commit messages should answer "what this commit does, and why it was done"
• Prioritize explaining the purpose/reason of the change, rather than just describing the change itself
• Maintain commit message accuracy: Small changes should have specific descriptions, avoid being too general
  • Even if only a small detail is modified, specifically explain what was changed
  • For example: "Update user login API to add verification code validation" is better than "Update API"
• Take user feedback seriously: If the user thinks the commit message is not good, adjust and optimize it immediately
• Prioritize using conversation context to understand real intentions
• When unsure about the change intent, ask the user

Start Conversation

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

我将帮你：

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

注意：

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

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