yy-commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

yy-commit

此技能帮助用户创建高质量的 Git 提交，生成规范的中文提交信息。

This skill helps users create high-quality Git commits and generate standardized Chinese commit messages.

使用场景

Usage Scenarios

用户说”提交代码”、”commit”、”创建提交”
用户说”保存更改”、”暂存更改”
用户完成某个功能或修复后需要提交

不应触发：

用户只是查看 git 状态或历史
用户要求执行 git push、pull、merge 等其他操作
用户要求修改代码或实现功能

When users say "submit code", "commit", "create a commit"
When users say "save changes", "stage changes"
When users need to commit after completing a feature or fix

Should NOT trigger:

When users only want to check git status or history
When users request to perform other operations like git push, pull, merge, etc.
When users request to modify code or implement features

指令

Instructions

1. 分析当前状态

1. Analyze Current Status

并行运行以下命令：

bash

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

理解：

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

Run the following commands in parallel:

bash

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

Understand:

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

2. 理解改动意图

2. Understand the Intention of Changes

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

代码变更分析：从 diff 中识别新增功能、修复问题、优化重构、文档更新等
对话上下文：提取用户想要实现的功能、提到的问题或需求
变更范围：确定影响的模块或功能区域
深层理解：不仅理解”做了什么”，更要理解”为什么要这么做”

Comprehend the purpose of this commit by integrating the following information:

Code Change Analysis: Identify new features, bug fixes, optimization refactoring, document updates, etc. from the diff
Conversation Context: Extract the features users want to implement, problems or requirements mentioned
Change Scope: Determine the affected modules or functional areas
Deep Understanding: Not only understand "what was done", but also "why it was done"

3. 智能选择暂存文件

3. Intelligently Select Staged Files

应该暂存的文件：

源代码文件（.ts, .js, .vue, .jsx, .tsx 等）
依赖与脚本声明文件（package.json 等）
文档文件（.md, .txt 等）
样式文件（.css, .scss 等）
测试文件

默认不暂存的项目配置文件（仅在用户明确授权时放行）：

构建与工具配置文件（包括但不限于 vite.config.ts、vite.config.js、vue.config.js、webpack.config.js、rollup.config.js、tsconfig.json、jsconfig.json、babel.config.js、postcss.config.js、eslint.config.js 等）
环境配置文件（包括但不限于 .env、.env.test、.env.production、.env.local 等）

配置文件放行规则：

用户明确说“提交所有文件”：允许一并暂存当前改动中的配置文件
用户明确说“连同配置文件一起提交”：允许一并暂存当前改动中的配置文件
用户明确点名具体文件：仅暂存用户点名的配置文件，例如“提交 vite.config.ts”或“提交 .env.production”
用户未明确授权：从暂存列表中排除上述配置文件，并在展示阶段明确告知排除原因

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

凭证文件（credentials.json, secrets.* 等）
私钥文件（_.key, _.pem 等）
大型二进制文件
node_modules 或其他依赖目录

应该忽略的文件：

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

Files that should be staged:

Source code files (.ts, .js, .vue, .jsx, .tsx, etc.)
Dependency and script declaration files (package.json, etc.)
Document files (.md, .txt, etc.)
Style files (.css, .scss, etc.)
Test files

Project configuration files not staged by default (only allowed when explicitly authorized by users):

Build and tool configuration files (including but not limited to vite.config.ts, vite.config.js, vue.config.js, webpack.config.js, rollup.config.js, tsconfig.json, jsconfig.json, babel.config.js, postcss.config.js, eslint.config.js, etc.)
Environment configuration files (including but not limited to .env, .env.test, .env.production, .env.local, etc.)

Configuration File Release Rules:

User explicitly says "commit all files": Allow staging configuration files in current changes together
User explicitly says "commit together with configuration files": Allow staging configuration files in current changes together
User explicitly specifies specific files: Only stage the configuration files specified by the user, e.g., "commit vite.config.ts" or "commit .env.production"
User does not explicitly authorize: Exclude the above configuration files from the staging list, and clearly inform the reason for exclusion during the display stage

Files that should trigger a warning (ask the user):

Credential files (credentials.json, secrets.*, etc.)
Private key files (*.key, *.pem, etc.)
Large binary files
node_modules or other dependency directories

Files that should be ignored:

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

4. 生成提交信息

4. Generate Commit Messages

默认遵循 Conventional Commits 规范：

type(scope): description

如果项目 AGENTS.md、README 或其他明确规则中定义了不同规范，则以项目约定为准。

Type（类型）：

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

Scope（范围）- 可选：

受影响的模块、组件或功能区域
优先使用具体的组件/模块名称，而不是泛化的类型名称
- ✅
```
DialogInstallationOptions
```
  （具体组件名）
- ❌
```
dialog
```
  （泛化类型）

Description（描述）：

使用中文（代码标识符、专有名词除外）
使用动词开头的祈使语气
精炼，不超过 50 个字符，一句话
优先说明”为什么”或”为了解决什么问题”，而不只是”做了什么”
精确性原则：当改动内容不多时，要具体描述变更的细节
避免使用”统一”、”所有”等绝对性词汇：基于实际修改的文件来描述

示例：

text

feat(auth): 添加 JWT 用户认证功能
fix(editor): 修复文件保存时的编码错误
docs(readme): 更新安装说明和环境要求
refactor(api): 简化请求拦截器逻辑
refactor: 重命名 plan/spec 技能避免与 trae 编辑器命令冲突

By default, follow the Conventional Commits specification:

type(scope): description

If different specifications are defined in the project's AGENTS.md, README or other explicit rules, follow the project's conventions.

Type:

```
feat
```
- New feature
```
fix
```
- Bug fix
```
docs
```
- Documentation update
```
style
```
- Code format adjustment (does not affect functionality)
```
refactor
```
- Refactoring (neither new feature nor bug fix)
```
perf
```
- Performance optimization
```
test
```
- Test-related
```
chore
```
- Build/tool/dependency-related
```
revert
```
- Revert commit

Scope (Optional):

Affected modules, components or functional areas
Prioritize using specific component/module names instead of generalized type names
- ✅
```
DialogInstallationOptions
```
  (specific component name)
- ❌
```
dialog
```
  (generalized type)

Description:

Use Chinese (except code identifiers and proper nouns)
Use imperative mood starting with a verb
Concise, no more than 50 characters, one sentence
Prioritize explaining "why" or "what problem it solves" rather than just "what was done"
Precision principle: When there are few changes, describe the details of the changes specifically
Avoid absolute words like "unified", "all": Describe based on the actual modified files

Examples:

text

feat(auth): 添加 JWT 用户认证功能
fix(editor): 修复文件保存时的编码错误
docs(readme): 更新安装说明和环境要求
refactor(api): 简化请求拦截器逻辑
refactor: 重命名 plan/spec 技能避免与 trae 编辑器命令冲突

5. 展示并确认

5. Display and Confirm

向用户展示：

将要暂存的文件列表
默认排除的配置文件列表（如存在）及排除原因
关键变更摘要（从 diff 提取的主要改动）
生成的提交信息

快速提交模式判断：

如果用户在请求中使用了以下关键词，则跳过确认步骤：

直接提交、立即提交、马上提交
无需确认、不用确认、跳过确认
直接 commit

常规模式： 用户可能对提交信息提出修改意见，应认真听取反馈并调整，直到用户满意。

展示格式：

text

即将提交以下更改：

📝 暂存文件：
  - src/auth/login.ts
  - src/components/LoginForm.vue

🚫 默认排除：
  - vite.config.ts（未收到明确授权，不随本次提交）

📊 主要变更：
  - 新增 JWT token 生成逻辑
  - 添加登录表单验证

💬 提交信息：
feat(auth): 添加 JWT 用户认证功能

是否确认提交？

Show the user:

List of files to be staged
List of configuration files excluded by default (if any) and the reason for exclusion
Key change summary (main changes extracted from diff)
Generated commit message

Quick Commit Mode Judgment:

Skip the confirmation step if the user uses the following keywords in the request:

Direct commit, immediate commit, commit now
No need to confirm, skip confirmation
Direct commit

Regular Mode: Users may provide feedback to modify the commit message, so listen carefully and adjust until the user is satisfied.

Display Format:

text

即将提交以下更改：

📝 暂存文件：
  - src/auth/login.ts
  - src/components/LoginForm.vue

🚫 默认排除：
  - vite.config.ts（未收到明确授权，不随本次提交）

📊 主要变更：
  - 新增 JWT token 生成逻辑
  - 添加登录表单验证

💬 提交信息：
feat(auth): 添加 JWT 用户认证功能

是否确认提交？

6. 执行提交

6. Execute Commit

用户确认后，按顺序执行（不可并行）：

bash

undefined

After user confirmation, execute in order (do not run in parallel):

bash

undefined

1. 暂存选定的文件

1. Stage selected files

git add <file1> <file2> ...

2. 创建提交

2. Create commit

git commit -m “<提交信息>”


**提交信息格式：**

- 单次改动较少：仅使用 title 即可
- 单次改动较多：在 title 后添加 body，以列表形式说明具体改动点

```text
docs(yy-comment): 补充触发示例和判断标准

- 补充用户输入触发示例，区分文件和函数两种场景
- 新增内部注释判断标准表格，量化注释决策
- 补充输出格式示例，展示统计表格格式

禁止事项：

禁止添加
```
Co-Authored-By:
```
等署名备注
body 内容使用列表形式，每项以
```
- 
```
开头
body 每项简洁明了，一句话说明一个改动点

git commit -m "<commit message>"


**Commit Message Format:**

- Few changes in a single commit: Only use the title
- Many changes in a single commit: Add a body after the title, listing specific changes in bullet points

```text
docs(yy-comment): 补充触发示例和判断标准

- 补充用户输入触发示例，区分文件和函数两种场景
- 新增内部注释判断标准表格，量化注释决策
- 补充输出格式示例，展示统计表格格式

Prohibited Items:

Do not add signature remarks like
```
Co-Authored-By:
```
Use bullet points for body content, each starting with
```
- 
```
Each bullet point in the body is concise, explaining one change in one sentence

7. 输出结果

7. Output Results

输出提交结果，包括：

提交的文件列表
提交信息
提交哈希值

Output the commit results, including:

List of committed files
Commit message
Commit hash

特殊情况处理

Special Case Handling

多个独立改动

Multiple Independent Changes

如果发现多个不相关的改动，建议用户分别提交：

text

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

建议分别提交以保持提交历史清晰。

If multiple unrelated changes are found, suggest users to commit separately:

text

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

建议分别提交以保持提交历史清晰。

无变更内容

No Changes

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

text

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

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

If git status shows no changes, inform the user:

text

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

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

冲突或未推送的提交

Conflicts or Unpushed Commits

如果发现有未推送的提交或合并冲突，提醒用户。

If unpushed commits or merge conflicts are found, remind the user.

注意事项

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 branches: If on main/master branch, remind users to consider working on feature branches
Respect .gitignore: Do not commit ignored files
Maintain atomicity: Each commit should be a logical unit

最佳实践

Best Practices

提交信息应该回答”这个提交做了什么，以及为什么要这么做”
优先说明改动的目的/原因，而不只是描述改动本身
保持提交信息的精确性：小改动要有具体的描述，避免过于宽泛
认真对待用户反馈：如果用户认为提交信息不够好，立即调整优化
优先使用对话上下文理解真实意图
当不确定变更意图时，询问用户
保持提交小而聚焦
使用有意义的 scope 帮助快速定位
提交信息涉及具体文件名时，必须保留原文件名，不得翻译

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 precision in commit messages: Small changes require specific descriptions, avoid being too broad
Take user feedback seriously: If users think the commit message is not good, adjust and optimize immediately
Prioritize using conversation context to understand real intentions
Ask users when unsure about the intention of changes
Keep commits small and focused
Use meaningful scope to help quickly locate
When commit messages involve specific file names, must retain the original file names, do not translate

路径格式规范

Path Format Specifications

在文档中提及文件路径时，优先使用相对路径
在终端中提及文件路径时，优先使用绝对路径
使用正斜杠作为路径分隔符，路径包含空格时使用引号包裹

When mentioning file paths in documents, prioritize using relative paths
When mentioning file paths in the terminal, prioritize using absolute paths
Use forward slashes as path separators, wrap paths containing spaces in quotes