yy-commit

Usage Scenarios

• 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

• 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. Analyze Current Status

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

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

2. Understand the Intention of Changes

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

3. Intelligently Select Staged Files

• 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

• 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.)

• 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

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

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

4. Generate Commit Messages

type(scope): description

• 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

• Affected modules, components or functional areas
• Prioritize using specific component/module names instead of generalized type names
  • ✅

    DialogInstallationOptions

    (specific component name)
  • ❌

    dialog

    (generalized type)

• 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

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

5. Display and Confirm

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

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

即将提交以下更改：

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

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

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

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

是否确认提交？

6. Execute Commit

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

# 2. Create commit
git commit -m "<commit message>"

• 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

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

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

• 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. Output Results

• List of committed files
• Commit message
• Commit hash

Special Case Handling

Multiple Independent Changes

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

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

No Changes

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

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

Conflicts or Unpushed Commits

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 branches: If on main/master branch, remind users to consider working on feature branches
4. Respect .gitignore: Do not commit 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 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