commit-message

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git Commit Message

Git提交信息

Instructions

操作说明

When this skill is invoked, follow these steps:

Check if there are staged changes: Run
```
git status
```
If the output of
```
git status
```
contains
```
Changes not staged for commit
```
, then:
- Generate an interactive yes/no prompt artifact asking "You have unstaged changes. Would you like me to stage your changes?"
- Upon confirmation, proceed by adding the staged changes
If the output of
```
git status
```
contains
```
nothing to commit, working tree clean
```
, then:
- Display response to the user: "No changes found. Please make changes to your files before trying to commit."
- Stop and exit the skill.
Only proceed if all changes have been staged, and there are no unstaged changes.
Check current branch: Run
```
git branch --show-current
```
to determine the current branch.
- If the current branch is
```
main
```
  or
```
master
```
  or
```
dev
```
  or
```
development
```
  :
  - Inform the user they are committing directly to the mainline branch
  - Generate an interactive yes/no prompt artifact asking "You're on the
```
<branch>
```
    branch. Would you like me to create the branch
```
<branch-name>
```
    for this commit?" Mention the new branch name.
  - Upon confirmation:
    - Analyze the staged changes (run
      git diff --cached
      if needed) to determine the appropriate branch type and a short task description
    - Generate a branch name in the format
      <type>/<task-description>
      (see Branch Naming Format section below). Be specific rather than generic in branch name, ie
      feature/switch-to-branch
      instead of
      feature/update-commit-skill
    - Present the suggested branch name to the user for approval
    - Upon approval, create and switch to the new branch using
      git switch -c <branch-name>
  - If the user declines, continue committing on the current branch
Get details of staged changes: Run
```
git diff --cached
```
to get the details of the staged changes. Review the diff output to understand:
- What files were modified
- What functionality changed
- The purpose and impact of the changes
Determine emoji usage:
- Search the user's original request for keywords like "emoji", "gitmoji", "with emoji", or "use emoji"
- By default (if no emoji keywords found): Generate the commit message in standard format WITHOUT any emojis
- If the user explicitly asks for emojis: Add emojis using the mapping table below, placing the emoji before the type
Generate commit message: Create a commit message following the semantic commit format below, ensuring:
- Appropriate commit type (feat, fix, docs, etc.)
- Only put a gitmoji in first line if user specified gitmoji or emoji
- Relevant scope based on affected codebase area
- Clear, imperative subject line under 50 characters
- Body and footer if needed for complex changes
- Add line breaks in the body if there are multiple sentences.
Present to user for commit approval:
- Display the formatted commit message for review (without showing the git command)
- Generate an interactive yes/no prompt artifact asking "Would you like me to create this commit?"
- Upon confirmation, proceed to create the commit
Present to user for push confirmation:

Once the commit is created, generate an interactive yes/no prompt asking "Would you like me to push this to the remote?"
Upon confirmation, proceed with the push operation

调用此技能时，请遵循以下步骤：

检查是否有暂存变更：执行
```
git status
```
如果
```
git status
```
输出包含
```
Changes not staged for commit
```
，则：
- 生成交互式确认提示：“您存在未暂存的变更，是否需要我帮您暂存这些变更？”
- 用户确认后，执行变更暂存操作
如果
```
git status
```
输出包含
```
nothing to commit, working tree clean
```
，则：
- 向用户提示：“未检测到任何变更，请先对文件进行修改后再尝试提交。”
- 终止并退出此技能
仅当所有变更已暂存且无未暂存变更时，才继续后续操作
检查当前分支：执行
```
git branch --show-current
```
确定当前分支
- 如果当前分支为
```
main
```
  、
```
master
```
  、
```
dev
```
  或
```
development
```
  ：
  - 告知用户正在直接向主线分支提交
  - 生成交互式确认提示：“您当前在
```
<branch>
```
    分支，是否需要我为此次提交创建
```
<branch-name>
```
    分支？”，并说明新分支名称
  - 用户确认后：
    - 分析暂存的变更（必要时执行
      git diff --cached
      ），确定合适的分支类型和简短任务描述
    - 按照
      <type>/<task-description>
      格式生成分支名称（详见下方分支命名格式），分支名称需具体而非通用，例如使用
      feature/switch-to-branch
      而非
      feature/update-commit-skill
    - 将建议的分支名称展示给用户确认
    - 用户确认后，执行
      git switch -c <branch-name>
      创建并切换到新分支
  - 用户拒绝的话，继续在当前分支提交
获取暂存变更详情：执行
```
git diff --cached
```
获取暂存变更的详细信息，分析输出内容以了解：
- 哪些文件被修改
- 功能发生了哪些变更
- 变更的目的和影响
确定是否使用表情：
- 搜索用户原始请求中是否包含“emoji”、“gitmoji”、“with emoji”或“use emoji”等关键词
- 默认（未检测到表情关键词）：生成标准格式的提交信息，不包含任何表情
- 用户明确要求使用表情时：按照下方映射表添加表情，将表情放在类型之前
生成提交信息：按照语义化提交格式创建提交信息，确保：
- 选择合适的提交类型（feat、fix、docs等）
- 仅当用户指定使用gitmoji或emoji时，才在第一行添加表情
- 根据受影响的代码区域添加相关范围
- 主题行使用祈使语气，长度不超过50个字符
- 复杂变更可添加正文和页脚
- 正文包含多个句子时需换行
提交确认：
- 展示格式化后的提交信息供用户审核（不显示Git命令）
- 生成交互式确认提示：“是否需要我创建此次提交？”
- 用户确认后，执行提交操作
推送确认：
- 提交创建完成后，生成交互式确认提示：“是否需要我将此次提交推送到远程仓库？”
- 用户确认后，执行推送操作

Commands to get details of staged changes

获取暂存变更详情的命令

Note:

git diff --cached

and

git diff --staged

are equivalent commands - both show staged changes.

注意：

git diff --cached

和

git diff --staged

是等效命令，均可查看暂存变更

Show which files are staged, modified, or untracked

查看已暂存、已修改或未跟踪的文件

git status

Show detailed line-by-line changes in staged files

查看暂存文件的逐行详细变更

git diff --staged

Show summary of staged changes with file names and line counts

查看暂存变更的摘要，包含文件名和行数统计

git diff --staged --stat

Show detailed changes for a specific staged file

查看特定暂存文件的详细变更

git diff --staged path/to/file

Commit Message Format

提交信息格式

The basic semantic message format is:

text

<type>(<scope>): <subject>

<body>

<footer>

Where:

```
<type>
```
: The type of change (see list below)
```
<scope>
```
: Optional, the area of codebase affected
```
<subject>
```
: Brief description in imperative mood
```
<body>
```
: Optional, detailed explanation
```
<footer>
```
: Optional, references to issues or breaking changes

基础语义化提交信息格式如下：

text

<type>(<scope>): <subject>

<body>

<footer>

参数说明：

```
<type>
```
：变更类型（详见下方列表）
```
<scope>
```
：可选，受影响的代码区域
```
<subject>
```
：简短描述，使用祈使语气
```
<body>
```
：可选，详细说明
```
<footer>
```
：可选，关联问题或标注破坏性变更

Commit Types

提交类型

The most common types are:

feat: A new feature
fix: A bug fix
docs: Documentation changes
style: Changes that don't affect code meaning (formatting, semicolons, etc.)
refactor: Code changes that neither fix bugs nor add features
perf: Changes that improve performance
test: Adding or updating tests
chore: Changes to build process, dependencies, or tooling

Scope is optional and specifies which part of the codebase is affected, like feat(auth): add login validation or fix(api): handle null responses.

Subject is a short, imperative description—start with a verb and keep it under 50 characters. Use present tense: "add feature" not "added feature."

Body is optional but useful for longer commits. It explains the why and what in more detail, usually wrapped at 72 characters. Separate it from the subject with a blank line.

Footer is optional and often used for referencing issues: Closes #123 or Fixes #456.

A practical example: feat(checkout): add paypal payment option

Added integration with PayPal's API
Implemented error handling

Closes #234

最常用的类型包括：

feat：新增功能
fix：修复Bug
docs：文档变更
style：不影响代码逻辑的格式调整（如格式化、分号补全等）
refactor：代码重构（既不修复Bug也不新增功能）
perf：性能优化
test：新增或更新测试
chore：构建流程、依赖或工具类变更

范围为可选参数，用于指定受影响的代码部分，例如

feat(auth): add login validation

或

fix(api): handle null responses

主题行需简短、使用祈使语气，以动词开头，如“add feature”而非“added feature”，长度控制在50字符以内

正文为可选内容，适用于较复杂的提交，用于详细说明变更的原因和内容，每行建议不超过72字符，与主题行之间用空行分隔

页脚为可选内容，常用于关联问题，格式如

Closes #123

或

Fixes #456

实际示例： feat(checkout): add paypal payment option

Added integration with PayPal's API
Implemented error handling

Closes #234

Branch Naming Format

分支命名格式

When creating a branch, use the following format:

text

<type>/<task-description>

Where:

```
<type>
```
: One of the branch types listed below
```
<task-description>
```
: A short hyphenated description of the task (3-4 words max, use hyphens instead of spaces)

创建分支时，请遵循以下格式：

text

<type>/<task-description>

参数说明：

```
<type>
```
：分支类型（详见下方列表）
```
<task-description>
```
：简短的连字符分隔任务描述（最多3-4个词，用连字符代替空格）

Branch Types

分支类型

Type	Usage
feature	New feature for the user
fix	Bug fix for the user
docs	Documentation changes
style	Formatting, missing semicolons, etc.
refactor	Refactoring production code
test	Adding missing tests, refactoring tests
chore	Updating grunt tasks, nothing that an external user would see

类型	用途
feature	为用户新增功能
fix	为用户修复Bug
docs	文档变更
style	格式调整（如补充分号等），不影响代码逻辑
refactor	生产代码重构
test	新增缺失测试或重构测试
chore	更新构建任务等外部用户不可见的变更

Example Branch Names

分支名称示例

```
feature/add-user-auth
```
```
fix/null-response-handling
```
```
docs/update-install-guide
```
```
style/reformat-buttons
```
```
refactor/simplify-data-logic
```
```
test/add-edge-cases
```
```
chore/upgrade-dependencies
```

```
feature/add-user-auth
```
```
fix/null-response-handling
```
```
docs/update-install-guide
```
```
style/reformat-buttons
```
```
refactor/simplify-data-logic
```
```
test/add-edge-cases
```
```
chore/upgrade-dependencies
```

Git Emoji Messages

Git表情提交信息

Only use emojis when explicitly requested by the user.

When emojis are requested, place the emoji at the start of the commit message, before the type. Format:

text

<emoji> <type>(<scope>): <subject>

仅当用户明确要求时才使用表情

用户要求使用表情时，需将表情放在提交信息的开头、类型之前，格式如下：

text

<emoji> <type>(<scope>): <subject>

Emoji Mappings to Types

表情与提交类型映射表

Type	Emoji
feat	✨
fix	🐛
docs	📚
style	💄
refactor	♻️
perf	⚡
test	✅
chore	🔨
ci	👷
build	📦
revert	⏮️
security	🔒
deps	📦

Example commit messages with emojis:

✨ feat(auth): add two-factor authentication 🐛 fix(api): handle null responses correctly 📚 docs: update installation guide 💄 style(ui): reformat button component ♻️ refactor(core): simplify data processing logic ⚡ perf(database): optimize query performance ✅ test(utils): add edge case tests 🔨 chore: upgrade dependencies 👷 ci: add GitHub Actions workflow 📦 build: update webpack config 🔒 security: patch XSS vulnerability

类型	表情
feat	✨
fix	🐛
docs	📚
style	💄
refactor	♻️
perf	⚡
test	✅
chore	🔨
ci	👷
build	📦
revert	⏮️
security	🔒
deps	📦

带表情的提交信息示例：

Guidelines for Commit Messages

提交信息规范

When generating commit messages, follow these rules:

ensure the subject line is lowercase only
Keep the first line under 50 characters for better readability in git logs
Be descriptive rather than technical: Explain what changed from a functional perspective, not implementation details
List changes in bullet form, 1 item per line rather than writing long sentences. Keep bullets to 6 points or less.
Use imperative mood: "add feature" not "added feature" or "adds feature"
Include scope when relevant: Helps identify which part of the codebase is affected
Add body for additional context: Explain the why and what in more detail when the subject alone isn't sufficient
Reference issues in footer: Use "Closes #123" or "Fixes #456" when applicable

生成提交信息时，请遵循以下规则：

主题行全部使用小写
第一行长度控制在50字符以内，提升Git日志的可读性
描述需侧重功能而非技术实现：从功能角度说明变更内容，而非具体实现细节
使用列表形式列举变更，每行一个条目，最多不超过6条
使用祈使语气：如“add feature”而非“added feature”或“adds feature”
相关情况下添加范围：帮助识别受影响的代码区域
必要时添加正文：当主题行无法充分说明时，补充变更的原因和细节
页脚关联问题：适用时使用
```
Closes #123
```
或
```
Fixes #456
```
格式

Output Format

输出格式

When presenting the generated commit message to the user, use this format:

markdown

Here's the suggested commit message based on your staged changes:

`
<generated commit message>
`

向用户展示生成的提交信息时，请使用以下格式：

markdown

Here's the suggested commit message based on your staged changes:

`
<generated commit message>
`

Important Notes

重要注意事项

Do not run
```
git commit
```
or
```
git push
```
without user approval
Do not add Co-Authored-By trailers: Commits should only show the user as the author. Never add "Co-Authored-By: Claude Sonnet noreply@anthropic.com" or any similar co-author trailers to commit messages
Analyze all staged files: If there are many staged files, review each one to ensure the commit message accurately reflects all changes

未获得用户确认前，不得执行
```
git commit
```
或
```
git push
```
命令
不得添加Co-Authored-By信息：提交信息中只能显示用户作为作者，禁止添加
```
Co-Authored-By: Claude Sonnet <noreply@anthropic.com>
```
或类似的共同作者信息
分析所有暂存文件：若存在多个暂存文件，需逐一检查确保提交信息准确反映所有变更内容