SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsgit-cmsg

git-cmsg

Writing & research

View repository

Updated 10-16 01:17

About this skill

Git Commit Message Generator

Generate Conventional Commits format commit messages in Chinese. Commit but never push.

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: Closes # 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

1. **Analyze staged changes first.** Run `git diff --cached` to understand what changed. Never guess.
2. **Determine type from changes, not from user description.** If user says "update" but the change adds a feature, use `feat`.
3. **Scope is optional but recommended.** Infer from changed file paths (package name, module name, directory). Use one scope per commit.
4. **Subject line:** Chinese, imperative mood, no period, under 50 chars. Concise summary of WHAT and WHY, not HOW.
5. **Body:** Chinese, explain WHY the change was made. Use numbered list for multiple changes. One change per line.
6. **Do NOT include HOW details** (implementation specifics) in the message.
7. **Commit but do NOT push.** Run `git commit` only. Never `git push`.
8. **必须等待用户确认。** 生成 commit message 后，展示给用户并等待明确同意。用户未回复前禁止执行 `git commit`。如果用户提出修改意见，按意见调整后再次展示确认。
9. **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:

1. **Claude Code:** use `AskUserQuestion` with the listed `question`, `header`, and `options`.
2. **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)`.
3. **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

Before generating the commit message, inspect staged files for files that should not be committed.

### Detection Rules

Flag staged files matching any of these patterns:

| 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/`, `Gopkg.lock` (if not needed) |
| Secrets/Credentials | `.env`, `*.pem`, `*.key`, `*.p12`, `credentials.*`, `*.secret`, `id_rsa*` |
| Generated files | `*.min.js`, `*.min.css`, `*.generated.*`, `*.pb.go`, `*.mock.go` (unless intentional) |
| Log/Temp | `*.log`, `*.tmp`, `*.bak`, `*.cache`, `.cache/` |
| OS files | `Thumbs.db`, `Desktop.ini`, `.DS_Store` |

### Workflow
  1. git diff --cached --name-only → Get staged file list
  2. Match against detection rules
  3. If suspicious files found: a. List them with reasons b. Use Decision UI to ask: remove from staging, or confirm intentional commit
    • question: "Found files that may not should be committed, how to handle?"
    • header: "Suspicious File Handling"
    • id: "suspicious_file_action"
    • options: [ { label: "Remove files", description: "Remove these files from the staging area, but keep them in the working directory" }, { label: "Continue committing", description: "Confirm that these files are intended to be committed" }, { label: "Cancel operation", description: "Cancel the current commit operation" } ] c. 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
      • question: "Create/update .gitignore file?"
      • header: "Git Ignore File"
      • id: "gitignore_action"
      • options: [ { label: "Create/update", description: "Create or update the .gitignore file to ignore these patterns" }, { label: "Do not handle", description: "Do not create/update the .gitignore file" }, { label: "Cancel operation", description: "Cancel the current commit operation" } ] d. After user decision, proceed with remaining staged files
  4. If no suspicious files, proceed normally

### .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 diff --cached --stat → Overview of changes

  2. git diff --cached --name-only → Staged file list

  3. Pre-commit file check → Detect suspicious files, handle .gitignore ⚠️ If suspicious files are found, MUST STOP and wait for the user's decision before continuing

  4. git diff --cached → Detailed diff (after any file removals)

  5. Analyze: type + scope + subject + body

  6. Add Co-authored-by trailer (fallback chain: model → client → omit): a. Detect model name (priority: ~/.trae/traecli.yaml → model.name field → $ANTHROPIC_MODEL env → self-identify from system prompt) b. If model name starts with "ark-", prefer traecli.yaml → model.name as the actual 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" g. Format: Co-authored-by: {model_name} ({provider}) <noreply@{provider_domain}>

    Provider Mapping:

    Prefix/Keyword Provider Domain
    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

  7. ⚠️ MUST STOP: Use Decision UI to display the generated commit message and wait for user confirmation

    • question: "Does the generated commit message meet the requirements?\n\nCommit message preview:\n\n{commit_message}\n"
    • header: "Commit Message Confirmation"
    • id: "commit_message_action"
    • options: [ { label: "Commit and push", description: "Use this commit message to commit and directly push to the remote repository" }, { label: "Confirm commit", description: "Use this commit message to commit" }, { label: "Regenerate", description: "Re-analyze the code changes and generate a new commit message" }, { label: "Cancel operation", description: "Cancel the current commit operation" } ]

  8. git commit -m "" → Execute commit (only after user confirms)

  9. If user chose "Commit and push": git push → Execute push (only after commit is successful)

  10. 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): Optimize metric reporting logic and adjust handleBinlogMessage parameters

  1. Refactor the emitCounter function, remove the fixed name parameter, build in the metric name and pass dimension information via tagkv
  2. Adjust the handleBinlogMessage signature, add a topic parameter to pass the binlog topic
  3. Unify the label format of all metric reporting, and add dimension information such as binlog topic and failure reason
  4. Adjust the association logic between logs and metric reporting, and remove duplicate metric calls

Co-authored-by: GLM-5.1 (Zhipu AI) noreply@zhipuai.cn


Bad:

fix: Fixed some issues

  • Changed the code
  • Fixed the bug
(vague, no real information)


## Edge Cases

- **No staged changes:** Warn user to `git add` first. Do not 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.