Git Commit Message Generator
Automatically stage all changes, let LLM judge if new files are safe to commit, then generate Conventional Commits format commit messages in Chinese.
When to Use
- User wants to commit code changes
- User asks to generate a commit message
- User mentions "提交", "commit", "commit message"
Conventional Commits Specification
Format:
<type>(<scope>): <subject>
<body>
BREAKING CHANGE: <description>
Closes #<issue>
Co-authored-by: {model_name} <{model_email}>
All text must be in Chinese except type, scope, and special tokens (BREAKING CHANGE, Closes).
Types
| Type |
Chinese |
When |
| feat |
新增功能 |
New feature |
| fix |
修复缺陷 |
Bug fix |
| docs |
文档变更 |
Documentation only |
| style |
代码格式 |
Formatting, whitespace, semicolons (no logic change) |
| refactor |
重构 |
Neither new feature nor bug fix |
| perf |
性能优化 |
Performance improvement |
| test |
测试相关 |
Adding or fixing tests |
| chore |
构建/工具/依赖 |
Build, tools, dependencies |
| ci |
CI/CD 配置 |
CI/CD configuration |
| revert |
回退提交 |
Reverting a commit |
| build |
构建系统 |
Build system or external dependencies |
Rules
- Auto-stage all changes first. Run
git add . to automatically stage all modified and untracked files. Do NOT ask user to git add manually.
- LLM judges new file safety. For every untracked/new file, intelligently determine if it's safe to commit. Consider: filename, file extension, likely content, and purpose.
- If all files are safe, proceed automatically. No need to stop for confirmation on file safety if LLM determines all files are appropriate to commit.
- Analyze staged changes. Run
git diff --cached to understand what changed. Never guess.
- Determine type from changes, not from user description. If user says "update" but the change adds a feature, use
feat.
- Scope is optional but recommended. Infer from changed file paths (package name, module name, directory). Use one scope per commit.
- Subject line: Chinese, imperative mood, no period, under 50 chars. Concise summary of WHAT and WHY, not HOW.
- Body: Chinese, explain WHY the change was made. Use numbered list for multiple changes. One change per line.
- Do NOT include HOW details (implementation specifics) in the message.
- Commit but do NOT push. Run
git commit only. Never git push.
- 必须等待用户确认。 生成 commit message 后，展示给用户并等待明确同意。用户未回复前禁止执行
git commit。如果用户提出修改意见，按意见调整后再次展示确认。
- Use the current agent's question tool. Claude Code should use
AskUserQuestion. Codex should use request_user_input when that tool is listed, available, and permitted in the current mode. If no structured question tool is available or the tool call fails, ask the same question in plain text and wait for the user's reply.
Decision UI
For every user decision in this skill, use this order:
- Claude Code: use
AskUserQuestion with the listed question, header, and options.
- Codex: use
request_user_input with one question object. Include header, a stable snake_case id, question, and 2-3 options. Put the recommended option first and suffix its label with (Recommended).
- Fallback: if the current agent does not expose either structured question tool, or the tool is unavailable, not permitted, or fails, ask the same options as plain text. Do not continue until the user clearly chooses an option.
Never invent a tool name that is not available in the current runtime.
Pre-commit File Check
Auto-stage first: Always run git add . at the start to stage all changes automatically.
LLM File Safety Judgment
For every new/untracked file being staged, use LLM intelligence to judge if it should be committed:
Judgment Criteria:
- File type: Is this a source code file, config file, documentation, or binary/blob?
- File name: Does the name suggest it contains secrets, credentials, or temporary data?
- Project context: Does this file belong in the repository based on the project's language/framework?
- Common sense: Would most developers commit this file in a similar project?
Automatic Action Rules:
- ✅ Safe to commit: Source code (
.go, .py, .js, .ts, .java, etc.), config files (.json, .yaml, .yml, .toml), documentation (.md, .txt), tests, assets that are clearly part of the project. Proceed automatically, no need to ask.
- ⚠️ Ask user: Large binary files, files with suspicious extensions, files that look like they might contain secrets, or files whose purpose is unclear.
- ❌ Auto-remove: Files matching the known bad patterns below. Auto-unstage these and inform user.
Known Bad Patterns (Auto-remove)
Auto-unstage files matching these without asking:
| Category |
Patterns |
| IDE/Editor |
.idea/, .vscode/, *.swp, *.swo, *~, .DS_Store |
| Build output |
*.o, *.a, *.so, *.exe, *.dll, *.pyc, __pycache__/, *.class, *.jar, *.war, dist/, build/, out/, target/ |
| Dependencies |
node_modules/, vendor/, venv/, .venv/ |
| Secrets/Credentials |
.env, *.pem, *.key, *.p12, credentials.*, *.secret, id_rsa* |
| Log/Temp |
*.log, *.tmp, *.bak, *.cache, .cache/ |
| OS files |
Thumbs.db, Desktop.ini, .DS_Store |
Workflow
1. git add . → Auto-stage ALL changes (modified + untracked files)
2. git diff --cached --name-only → Get staged file list
3. Check for known bad patterns → Auto-unstage them, inform user
4. For remaining new files → LLM safety judgment
a. If all judged safe → Proceed automatically (no user prompt)
b. If uncertain/suspicious → Use Decision UI to confirm
5. If patterns suggest missing .gitignore:
- Check if .gitignore exists and already covers these patterns
- If not covered, propose .gitignore additions
- Use Decision UI to ask: whether to create/update .gitignore
6. Proceed with commit message generation
.gitignore Handling
- If
.gitignore does not exist in the repo root, offer to create one with appropriate patterns for the project's language/framework.
- If
.gitignore exists but misses patterns for the flagged files, propose appending the missing patterns.
- Never modify
.gitignore without user confirmation.
- If user confirms
.gitignore update, stage the .gitignore change and include it in the same commit with type chore.
Workflow
1. git add . → Auto-stage ALL changes (no need to ask user to git add)
2. git diff --cached --stat → Overview of changes
3. git diff --cached --name-only → Staged file list
4. Pre-commit file check:
a. Auto-unstage known bad patterns and inform user
b. LLM safety judgment on new files
c. If all safe → proceed automatically
d. If uncertain → stop for user confirmation
5. git diff --cached → Detailed diff (after any file removals)
6. Analyze: type + scope + subject + body
7. Add Co-authored-by trailer (fallback chain: model → client → omit):
a. **Detect model name** (priority order, highest first):
1. **Claude Code system prompt** - look for exact line: "You are powered by the model <model_name>"
2. `~/.trae/traecli.yaml` → `model.name` field
3. `$ANTHROPIC_MODEL` environment variable
4. Self-identify from system prompt metadata
b. **CRITICAL**: If system prompt says "ark-code-latest", use that EXACTLY. Do NOT translate to Claude 4.7 or any other model name"
c. **Infer provider** from model name prefix (see Provider Mapping below)
d. **If no prefix match**, infer provider from `$ANTHROPIC_BASE_URL` domain (see Base URL Fallback below)
e. **If still unresolved**, omit the Co-authored-by line entirely — never use "Unknown"
f. Format: `Co-authored-by: {model_name} ({provider}) <noreply@{provider_domain}>`
Provider Mapping:
| Prefix/Keyword | Provider | Domain |
|-----------------------|------------------|---------------------|
| ark-* | ByteDance (ARK) | volcesengine.com |
| glm-*, GLM-* | Zhipu AI | zhipuai.cn |
| claude-*, Claude* | Anthropic | anthropic.com |
| gpt-*, o1-*, o3-* | OpenAI | openai.com |
| deepseek-* | DeepSeek | deepseek.com |
| qwen-*, Qwen* | Alibaba Cloud | alibabacloud.com |
| doubao-* | ByteDance | bytedance.com |
| llama-*, Llama* | Meta | meta.com |
| gemini-*, Gemini* | Google | google.com |
| mistral-*, Mistral* | Mistral AI | mistral.ai |
Base URL Fallback:
| Domain Pattern | Provider |
|------------------------|------------------|
| volces.com / ark.* | ByteDance (ARK) |
| anthropic.com | Anthropic |
| openai.com | OpenAI |
| deepseek.com | DeepSeek |
8. ⚠️ MUST STOP: 使用 Decision UI 展示生成的 commit message 并等待用户确认
- question: "生成的提交信息是否符合要求？\n\n提交信息预览：\n```\n{commit_message}\n```"
- header: "提交信息确认"
- id: "commit_message_action"
- options: [
{ label: "提交并推送", description: "使用此提交信息进行提交并直接 push 到远程仓库" },
{ label: "确认提交", description: "使用此提交信息进行提交" },
{ label: "重新生成", description: "重新分析代码变更并生成新的提交信息" },
{ label: "取消操作", description: "取消当前提交操作" }
]
9. git commit -m "<message>" → Execute commit (only after user confirms)
10. If user chose "提交并推送": git push → Execute push (only after commit is successful)
11. Show git log -1 --oneline → Confirm result
Subject Examples
Good:
feat(user): 新增用户注册接口fix(cache): 修复缓存过期时间未生效的问题refactor(handler): 优化指标打点逻辑并调整handleBinlogMessage参数perf(query): 减少数据库查询次数chore(deps): 升级Gin框架至v1.9.0
Bad:
feat(user): 新增了一个用户注册的接口功能 (too verbose)fix: fix bug (no scope, no detail)update code (not Conventional Commits)feat(user): add user register API (not Chinese)
Body Examples
Good:
refactor(handler): 优化指标打点逻辑并调整handleBinlogMessage参数
1. 重构emitCounter函数，移除固定name参数，内置指标名并通过tagkv传递维度信息
2. 调整handleBinlogMessage签名，新增topic参数用于传递binlog主题
3. 统一所有指标打点的标签格式，补充binlog主题、失败原因等维度信息
4. 调整日志和指标打点的关联逻辑，移除重复的指标调用
Co-authored-by: GLM-5.1 (Zhipu AI) <noreply@zhipuai.cn>
Bad:
fix: 修复了一些问题
- 改了代码
- 修了bug
(vague, no real information)
Edge Cases
- No changes at all: If
git add . results in empty staging area, inform user there are no changes to commit.
- Mixed types in one commit: Pick the most significant type. If a refactor also fixes a bug, use
fix if the bug fix is the primary intent, refactor if the restructuring is the primary intent.
- Multiple scopes: Use the most affected scope, or omit scope if no single scope dominates.
- Breaking changes: Always add
BREAKING CHANGE: footer in body.
- Auto-removed files: After auto-unstaging known bad files, if no files remain to commit, inform user.
1---2name: git-cmsg3description: Use when generating Git commit messages, writing commit messages, committing code, or when the user mentions commit、提交、commit message、提交信息. Automatically stages all changes by default, uses LLM to judge if new files should be committed, generates Conventional Commits format messages in Chinese.4---56# Git Commit Message Generator78Automatically stage all changes, let LLM judge if new files are safe to commit, then generate Conventional Commits format commit messages in Chinese.910## When to Use1112- User wants to commit code changes13- User asks to generate a commit message14- User mentions "提交", "commit", "commit message"1516## Conventional Commits Specification1718Format:1920```21<type>(<scope>): <subject>2223<body>2425BREAKING CHANGE: <description>26Closes #<issue>27Co-authored-by: {model_name} <{model_email}>28```2930**All text must be in Chinese** except type, scope, and special tokens (BREAKING CHANGE, Closes).3132## Types3334| Type | Chinese | When |35|------|---------|------|36| feat | 新增功能 | New feature |37| fix | 修复缺陷 | Bug fix |38| docs | 文档变更 | Documentation only |39| style | 代码格式 | Formatting, whitespace, semicolons (no logic change) |40| refactor | 重构 | Neither new feature nor bug fix |41| perf | 性能优化 | Performance improvement |42| test | 测试相关 | Adding or fixing tests |43| chore | 构建/工具/依赖 | Build, tools, dependencies |44| ci | CI/CD 配置 | CI/CD configuration |45| revert | 回退提交 | Reverting a commit |46| build | 构建系统 | Build system or external dependencies |4748## Rules49501. **Auto-stage all changes first.** Run `git add .` to automatically stage all modified and untracked files. Do NOT ask user to `git add` manually.512. **LLM judges new file safety.** For every untracked/new file, intelligently determine if it's safe to commit. Consider: filename, file extension, likely content, and purpose.523. **If all files are safe, proceed automatically.** No need to stop for confirmation on file safety if LLM determines all files are appropriate to commit.534. **Analyze staged changes.** Run `git diff --cached` to understand what changed. Never guess.545. **Determine type from changes, not from user description.** If user says "update" but the change adds a feature, use `feat`.556. **Scope is optional but recommended.** Infer from changed file paths (package name, module name, directory). Use one scope per commit.567. **Subject line:** Chinese, imperative mood, no period, under 50 chars. Concise summary of WHAT and WHY, not HOW.578. **Body:** Chinese, explain WHY the change was made. Use numbered list for multiple changes. One change per line.589. **Do NOT include HOW details** (implementation specifics) in the message.5910. **Commit but do NOT push.** Run `git commit` only. Never `git push`.6011. **必须等待用户确认。** 生成 commit message 后，展示给用户并等待明确同意。用户未回复前禁止执行 `git commit`。如果用户提出修改意见，按意见调整后再次展示确认。6112. **Use the current agent's question tool.** Claude Code should use `AskUserQuestion`. Codex should use `request_user_input` when that tool is listed, available, and permitted in the current mode. If no structured question tool is available or the tool call fails, ask the same question in plain text and wait for the user's reply.6263## Decision UI6465For every user decision in this skill, use this order:66671. **Claude Code:** use `AskUserQuestion` with the listed `question`, `header`, and `options`.682. **Codex:** use `request_user_input` with one question object. Include `header`, a stable snake_case `id`, `question`, and 2-3 options. Put the recommended option first and suffix its label with `(Recommended)`.693. **Fallback:** if the current agent does not expose either structured question tool, or the tool is unavailable, not permitted, or fails, ask the same options as plain text. Do not continue until the user clearly chooses an option.7071Never invent a tool name that is not available in the current runtime.7273## Pre-commit File Check7475**Auto-stage first:** Always run `git add .` at the start to stage all changes automatically.7677### LLM File Safety Judgment7879For every new/untracked file being staged, use LLM intelligence to judge if it should be committed:8081**Judgment Criteria:**821. **File type:** Is this a source code file, config file, documentation, or binary/blob?832. **File name:** Does the name suggest it contains secrets, credentials, or temporary data?843. **Project context:** Does this file belong in the repository based on the project's language/framework?854. **Common sense:** Would most developers commit this file in a similar project?8687**Automatic Action Rules:**88- ✅ **Safe to commit:** Source code (`.go`, `.py`, `.js`, `.ts`, `.java`, etc.), config files (`.json`, `.yaml`, `.yml`, `.toml`), documentation (`.md`, `.txt`), tests, assets that are clearly part of the project. **Proceed automatically, no need to ask.**89- ⚠️ **Ask user:** Large binary files, files with suspicious extensions, files that look like they might contain secrets, or files whose purpose is unclear.90- ❌ **Auto-remove:** Files matching the known bad patterns below. Auto-unstage these and inform user.9192### Known Bad Patterns (Auto-remove)9394Auto-unstage files matching these without asking:9596| Category | Patterns |97|----------|----------|98| IDE/Editor | `.idea/`, `.vscode/`, `*.swp`, `*.swo`, `*~`, `.DS_Store` |99| Build output | `*.o`, `*.a`, `*.so`, `*.exe`, `*.dll`, `*.pyc`, `__pycache__/`, `*.class`, `*.jar`, `*.war`, `dist/`, `build/`, `out/`, `target/` |100| Dependencies | `node_modules/`, `vendor/`, `venv/`, `.venv/` |101| Secrets/Credentials | `.env`, `*.pem`, `*.key`, `*.p12`, `credentials.*`, `*.secret`, `id_rsa*` |102| Log/Temp | `*.log`, `*.tmp`, `*.bak`, `*.cache`, `.cache/` |103| OS files | `Thumbs.db`, `Desktop.ini`, `.DS_Store` |104105### Workflow106107```1081. git add . → Auto-stage ALL changes (modified + untracked files)1092. git diff --cached --name-only → Get staged file list1103. Check for known bad patterns → Auto-unstage them, inform user1114. For remaining new files → LLM safety judgment112 a. If all judged safe → Proceed automatically (no user prompt)113 b. If uncertain/suspicious → Use Decision UI to confirm1145. If patterns suggest missing .gitignore:115 - Check if .gitignore exists and already covers these patterns116 - If not covered, propose .gitignore additions117 - Use Decision UI to ask: whether to create/update .gitignore1186. Proceed with commit message generation119```120121### .gitignore Handling122123- If `.gitignore` does not exist in the repo root, offer to create one with appropriate patterns for the project's language/framework.124- If `.gitignore` exists but misses patterns for the flagged files, propose appending the missing patterns.125- Never modify `.gitignore` without user confirmation.126- If user confirms `.gitignore` update, stage the `.gitignore` change and include it in the same commit with type `chore`.127128## Workflow129130```1311. git add . → Auto-stage ALL changes (no need to ask user to git add)1322. git diff --cached --stat → Overview of changes1333. git diff --cached --name-only → Staged file list1344. Pre-commit file check:135 a. Auto-unstage known bad patterns and inform user136 b. LLM safety judgment on new files137 c. If all safe → proceed automatically138 d. If uncertain → stop for user confirmation1395. git diff --cached → Detailed diff (after any file removals)1406. Analyze: type + scope + subject + body1417. Add Co-authored-by trailer (fallback chain: model → client → omit):142 a. **Detect model name** (priority order, highest first):143 1. **Claude Code system prompt** - look for exact line: "You are powered by the model <model_name>"144 2. `~/.trae/traecli.yaml` → `model.name` field145 3. `$ANTHROPIC_MODEL` environment variable146 4. Self-identify from system prompt metadata147 b. **CRITICAL**: If system prompt says "ark-code-latest", use that EXACTLY. Do NOT translate to Claude 4.7 or any other model name"148 c. **Infer provider** from model name prefix (see Provider Mapping below)149 d. **If no prefix match**, infer provider from `$ANTHROPIC_BASE_URL` domain (see Base URL Fallback below)150 e. **If still unresolved**, omit the Co-authored-by line entirely — never use "Unknown"151 f. Format: `Co-authored-by: {model_name} ({provider}) <noreply@{provider_domain}>`152153 Provider Mapping:154 | Prefix/Keyword | Provider | Domain |155 |-----------------------|------------------|---------------------|156 | ark-* | ByteDance (ARK) | volcesengine.com |157 | glm-*, GLM-* | Zhipu AI | zhipuai.cn |158 | claude-*, Claude* | Anthropic | anthropic.com |159 | gpt-*, o1-*, o3-* | OpenAI | openai.com |160 | deepseek-* | DeepSeek | deepseek.com |161 | qwen-*, Qwen* | Alibaba Cloud | alibabacloud.com |162 | doubao-* | ByteDance | bytedance.com |163 | llama-*, Llama* | Meta | meta.com |164 | gemini-*, Gemini* | Google | google.com |165 | mistral-*, Mistral* | Mistral AI | mistral.ai |166167 Base URL Fallback:168 | Domain Pattern | Provider |169 |------------------------|------------------|170 | volces.com / ark.* | ByteDance (ARK) |171 | anthropic.com | Anthropic |172 | openai.com | OpenAI |173 | deepseek.com | DeepSeek |1748. ⚠️ MUST STOP: 使用 Decision UI 展示生成的 commit message 并等待用户确认175 - question: "生成的提交信息是否符合要求？\n\n提交信息预览：\n```\n{commit_message}\n```"176 - header: "提交信息确认"177 - id: "commit_message_action"178 - options: [179 { label: "提交并推送", description: "使用此提交信息进行提交并直接 push 到远程仓库" },180 { label: "确认提交", description: "使用此提交信息进行提交" },181 { label: "重新生成", description: "重新分析代码变更并生成新的提交信息" },182 { label: "取消操作", description: "取消当前提交操作" }183 ]1849. git commit -m "<message>" → Execute commit (only after user confirms)18510. If user chose "提交并推送": git push → Execute push (only after commit is successful)18611. Show git log -1 --oneline → Confirm result187```188189## Subject Examples190191Good:192- `feat(user): 新增用户注册接口`193- `fix(cache): 修复缓存过期时间未生效的问题`194- `refactor(handler): 优化指标打点逻辑并调整handleBinlogMessage参数`195- `perf(query): 减少数据库查询次数`196- `chore(deps): 升级Gin框架至v1.9.0`197198Bad:199- `feat(user): 新增了一个用户注册的接口功能` (too verbose)200- `fix: fix bug` (no scope, no detail)201- `update code` (not Conventional Commits)202- `feat(user): add user register API` (not Chinese)203204## Body Examples205206Good:207```208refactor(handler): 优化指标打点逻辑并调整handleBinlogMessage参数2092101. 重构emitCounter函数，移除固定name参数，内置指标名并通过tagkv传递维度信息2112. 调整handleBinlogMessage签名，新增topic参数用于传递binlog主题2123. 统一所有指标打点的标签格式，补充binlog主题、失败原因等维度信息2134. 调整日志和指标打点的关联逻辑，移除重复的指标调用214215Co-authored-by: GLM-5.1 (Zhipu AI) <noreply@zhipuai.cn>216```217218Bad:219```220fix: 修复了一些问题221222- 改了代码223- 修了bug224```225(vague, no real information)226227228## Edge Cases229230- **No changes at all:** If `git add .` results in empty staging area, inform user there are no changes to commit.231- **Mixed types in one commit:** Pick the most significant type. If a refactor also fixes a bug, use `fix` if the bug fix is the primary intent, `refactor` if the restructuring is the primary intent.232- **Multiple scopes:** Use the most affected scope, or omit scope if no single scope dominates.233- **Breaking changes:** Always add `BREAKING CHANGE:` footer in body.234- **Auto-removed files:** After auto-unstaging known bad files, if no files remain to commit, inform user.
mnhkahn