git-cmsg

Git 提交信息生成器

自动暂存所有更改，让大模型判断新文件是否可以安全提交，然后生成中文 Conventional Commits 格式的提交信息。

使用场景

• 用户想要提交代码更改
• 用户要求生成提交信息
• 用户提到“提交”、“commit”或“commit message”

Git Tag 入口

• 用户只要求打 tag、升级版本标签，或显式调用 /git-tag / $git-tag 时，使用相邻的 git-tag skill，直接调用 cyeam tag。
• /git-tag 默认小版本升级；/git-tag major 大版本升级；/git-tag minor --dry-run 只预览。
• 只打 tag 时不进入下面的暂存、提交信息生成或提交确认流程。
• 用户同时要求提交和打 tag 时，先完成用户授权的提交，再使用 git-tag；普通提交不会自动打 tag。
• 修改 skill 文件本身不代表要求提交代码或创建标签。

Conventional Commits 规范

格式：

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

<body>

BREAKING CHANGE: <description>
Closes #<issue>
Co-authored-by: {model_name} <{model_email}>

除类型、范围和特殊标记（BREAKING CHANGE、Closes）外，所有文本都必须使用中文。

类型

类型	中文	适用场景
feat	新增功能	新功能
fix	修复缺陷	修复 Bug
docs	文档变更	仅文档变更
style	代码格式	格式、空白字符、分号（不改变逻辑）
refactor	重构	既非新增功能也非修复缺陷
perf	性能优化	性能改进
test	测试相关	添加或修复测试
chore	构建/工具/依赖	构建、工具、依赖
ci	CI/CD 配置	CI/CD 配置
revert	回退提交	回退某次提交
build	构建系统	构建系统或外部依赖

规则

1. 先自动暂存所有更改。 运行 git add . 自动暂存所有已修改和未跟踪的文件。不要要求用户手动运行 git add。
2. 由大模型判断新文件是否安全。 对每个未跟踪/新文件，智能判断是否适合提交。考虑文件名、扩展名、可能的内容和用途。
3. 如果所有文件都安全，则自动继续。 如果大模型判断所有文件都适合提交，无需暂停并确认文件是否安全。
4. 分析已暂存的更改。 运行 git diff --cached 了解发生了哪些变化。绝不要猜测。
5. 根据更改而非用户描述确定类型。 如果用户说“更新”，但更改新增了功能，则使用 feat。
6. 范围可选，但建议填写。 根据更改文件的路径推断（包名、模块名、目录）。每次提交使用一个范围。
7. 主题行： 使用中文和祈使语气，不加句号，少于 50 个字符。简洁概括做了什么以及原因，而非如何实现。
8. 正文： 使用中文说明更改原因。若有多项更改，使用编号列表。每行一项更改。
9. 不要在信息中写入如何实现的细节（实现细节）。
10. 提交但不要推送。 只运行 git commit。绝不要运行 git push。
11. 必须等待用户确认。 生成提交信息后，向用户展示并等待明确同意。用户未回复前禁止执行 git commit。如果用户提出修改意见，按意见调整后再次展示并等待确认。
12. 使用当前 Agent 的提问工具。 Claude Code 应使用 AskUserQuestion。如果 request_user_input 已列出、可用且当前模式允许，Codex 应使用该工具。如果没有可用的结构化提问工具，或工具调用失败，则用纯文本提出同样的问题并等待用户回复。

决策界面

对于此 skill 中的每项用户决策，按以下顺序操作：

1. Claude Code： 使用 AskUserQuestion，并提供列出的 question、header 和 options。
2. Codex： 使用 request_user_input，并提供一个问题对象。包含 header、稳定的 snake_case id、question 和 2-3 个选项。将推荐选项放在首位，并在其标签末尾加上 (Recommended)。
3. 回退方案： 如果当前 Agent 没有提供上述任一结构化提问工具，或工具不可用、不允许使用或调用失败，则用纯文本询问相同选项。在用户明确选择之前，不要继续。

绝不要臆造当前运行环境中不可用的工具名称。

提交前文件检查

先自动暂存： 始终在开始时运行 git add .，自动暂存所有更改。

LLM 文件安全判定

对于每个准备暂存的新文件／未跟踪文件，使用 LLM 智能判断是否应该提交：

判定标准：

1. **文件类型：**这是源代码文件、配置文件、文档，还是二进制文件／blob？
2. **文件名：**名称是否暗示文件包含机密、凭据或临时数据？
3. **项目上下文：**根据项目使用的语言／框架，此文件是否应纳入仓库？
4. **常识判断：**大多数开发者会在类似项目中提交此文件吗？

自动操作规则：

• ✅ **可以安全提交：**源代码（.go、.py、.js、.ts、.java 等）、配置文件（.json、.yaml、.yml、.toml）、文档（.md、.txt）、测试，以及明显属于项目的资源。自动继续，无需询问。
• ⚠️ **询问用户：**大型二进制文件、扩展名可疑的文件、看起来可能包含机密的文件，或用途不明确的文件。
• ❌ **自动移除：**匹配以下已知不良模式的文件。自动将这些文件从暂存区移除，并告知用户。

已知不良模式（自动移除）

无需询问，自动将匹配以下模式的文件从暂存区移除：

类别	模式
IDE／编辑器	.idea/、.vscode/、*.swp、*.swo、*~、.DS_Store
构建产物	*.o、*.a、*.so、*.exe、*.dll、*.pyc、__pycache__/、*.class、*.jar、*.war、dist/、build/、out/、target/
依赖项	node_modules/、vendor/、venv/、.venv/
机密／凭据	.env、*.pem、*.key、*.p12、credentials.*、*.secret、id_rsa*
日志／临时文件	*.log、*.tmp、*.bak、*.cache、.cache/
操作系统文件	Thumbs.db、Desktop.ini、.DS_Store

工作流

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 处理

• 如果仓库根目录中不存在 .gitignore，则提出创建一个包含适用于项目语言／框架的规则的文件。
• 如果 .gitignore 已存在，但缺少适用于已标记文件的规则，则提出追加缺失的规则。
• 未经用户确认，绝不修改 .gitignore。
• 如果用户确认更新 .gitignore，则暂存 .gitignore 的变更，并在同一次提交中以 chore 类型提交。

工作流

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

主题示例

良好：

• feat(user): 新增用户注册接口
• fix(cache): 修复缓存过期时间未生效的问题
• refactor(handler): 优化指标打点逻辑并调整handleBinlogMessage参数
• perf(query): 减少数据库查询次数
• chore(deps): 升级Gin框架至v1.9.0

不佳：

• feat(user): 新增了一个用户注册的接口功能（过于冗长）
• fix: fix bug（没有范围说明，也没有细节）
• update code（不符合 Conventional Commits）
• feat(user): add user register API（不是中文）

正文示例

良好：

refactor(handler): 优化指标打点逻辑并调整handleBinlogMessage参数

1. 重构emitCounter函数，移除固定name参数，内置指标名并通过tagkv传递维度信息
2. 调整handleBinlogMessage签名，新增topic参数用于传递binlog主题
3. 统一所有指标打点的标签格式，补充binlog主题、失败原因等维度信息
4. 调整日志和指标打点的关联逻辑，移除重复的指标调用

Co-authored-by: GLM-5.1 (Zhipu AI) <[email protected]>

不佳：

fix: 修复了一些问题

- 改了代码
- 修了bug

（内容含糊，没有实际信息）

边缘情况

• **完全没有变更：**如果 git add . 后暂存区为空，则告知用户没有变更可提交。
• **一次提交中包含多种类型：**选择最重要的类型。如果重构同时修复了 bug，且修复 bug 是主要意图，则使用 fix；如果调整结构是主要意图，则使用 refactor。
• **多个范围：**使用影响最大的范围；如果没有哪个范围占主导，则省略范围。
• **破坏性变更：**始终在正文中添加 BREAKING CHANGE: 页脚。
• **自动移除的文件：**自动将已知不良文件从暂存区移除后，如果没有剩余文件可提交，则告知用户。