yy-frontend-commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

yy-frontend-commit

目录范围限制：处理
src
目录下的所有文件，但以下目录下的文件禁止提交：
src/router
禁止目录定义在 SKILL.md 头部的
metadata.forbidden_directories
中，可根据项目需要自行调整。

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

src

目录之外的文件。

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.

Important Restrictions: Strictly prohibit processing files in forbidden directories, and also prohibit processing files outside the

src

directory.

使用场景

Usage Scenarios

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

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

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

Use this skill when the user mentions the following:

Submit code
Generate commit messages
Organize modified files

Important: Push operations are prohibited, but add and commit operations will be executed automatically.

工作流程

Workflow

阶段一：检查目录范围

Phase 1: Check Directory Scope

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

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

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

bash

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

这些命令帮助你理解：

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

After passing the directory check, run the following commands in parallel to understand the current status:

bash

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

These commands help you understand:

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

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

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

Filter out files under the

src

directory and not in forbidden directories (Note: Files in forbidden directories are not involved in submission, and files outside the src directory are also not involved in submission):

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

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

代码变更分析：从 diff 中识别：
- 新增了什么功能？
- 修复了什么问题？
- 优化或重构了什么？
- 更新了什么文档？
对话上下文：如果当前对话中有相关讨论，提取：
- 用户想要实现的功能
- 用户提到的问题或需求
- 之前讨论的改动意图
- 用户为什么要做这个改动？解决什么痛点？
深层理解：
- 不仅仅理解"做了什么"，更要理解"为什么要这么做"
- 这是解决了什么问题？避免了什么冲突？
- 这是为了支持什么新功能或改进什么体验？

Comprehensively understand the purpose and reason of this submission based on the following information:

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?
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?
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

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

应该暂存的文件：

源代码文件（.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 等）

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

Select files to stage according to the following principles:

Files that should be staged:

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

Files that should be warned about (ask the user):

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

Files that should be ignored:

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

If files that need warning are found, clearly inform the user and ask if they should be included.

阶段五：生成提交信息

Phase 5: Generate Commit Message

提交信息必须遵循格式：

type(scope): description

Type（类型）：

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

Scope（范围）- 可选：

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

Description（描述）：

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

示例：

优秀的提交信息：

text

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

需要改进的提交信息：

text

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

更好的版本：

text

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

Commit messages must follow the format:

type(scope): description

Type:

```
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

Scope - Optional:

Affected modules, components or functional areas
For example:
```
auth
```
,
```
api
```
,
```
ui
```

Description:

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"

Examples:

Excellent commit messages:

text

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

Commit messages that need improvement:

text

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

Better versions:

text

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

阶段六：展示并确认

Phase 6: Display and Confirm

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

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

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

使用以下格式：

markdown

即将提交以下更改：

📝 暂存文件：

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

📊 主要变更：

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

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

是否确认提交？

Before executing the submission, show the user:

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

Important Note: Users may propose modification suggestions for the commit message (e.g., think the message is too broad, not specific enough, etc.), you should carefully listen to user feedback and adjust the commit message until the user is satisfied.

Use the following format:

markdown

即将提交以下更改：

📝 暂存文件：

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

📊 主要变更：

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

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

是否确认提交？

阶段七：执行提交

Phase 7: Execute Commit

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

bash

undefined

After user confirmation, execute in order:

bash

undefined

1. 暂存文件

1. Stage files

git add <file1> <file2> ...

2. 创建提交（使用 HEREDOC 确保格式正确）

2. Create commit (use HEREDOC to ensure correct format)

注意：将 <当前 AI 模型名称> 替换为你实际使用的模型名称

Note: Replace <Current AI Model Name> with the actual model name you are using

git commit -m "$(cat <<'EOF' <提交信息>

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

git commit -m "$(cat <<'EOF' <提交信息>

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

3. 确认提交成功

3. Confirm commit success

git status git log -1


**重要提示**：

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

git status git log -1


**Important Notes**:

- 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

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

text

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

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

你希望如何处理？

If multiple unrelated changes are found (e.g., both new features and bug fixes), suggest the user submit separately:

text

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

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

你希望如何处理？

无变更内容

No Change Content

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

text

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

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

If git status shows no changes, inform the user:

text

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

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

冲突或未推送的提交

Conflicts or Unpushed Commits

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

text

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

If there are unpushed commits or merge conflicts, remind the user to push or resolve conflicts first:

text

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

注意事项

Notes

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

Never skip hooks: Do not use flags like
```
--no-verify
```
Do not force operations: Do not use
```
--force
```
or
```
--amend
```
(unless explicitly requested by the user)
Protect main branch: If on main/master branch, remind the user to consider working on a feature branch
Respect .gitignore: Do not suggest submitting ignored files
Maintain atomicity: Each commit should be a logical unit

最佳实践

Best Practices

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

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

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

markdown

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

我将帮你：

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

注意：

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

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

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

When the user starts this skill, respond in the following way:

markdown

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

我将帮你：

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

注意：

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

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

Then execute step by step according to the workflow.