SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsgit-commit-doc

git-commit-doc

Writing & research

View repository

Updated 10-15 23:33

About this skill

Git Commit Doc

Overview

Write commit messages in the Chinese Conventional Commits style: keep the title type(scope): 中文一句话, and use a Chinese hyphenated list in the body to describe the key changes. This specification was distilled from the commit history of xintong-java , but it should be used as a general-purpose commit document.

Workflow

  1. First check for uncommitted changes, prioritizing reading the staged diff; if there is no staged content, then read the working tree diff, and clearly state which part of the changes the commit document is based on.
  2. If both staged and unstaged changes exist, by default generate the commit document targeting "all uncommitted changes," unless the user explicitly asks to look only at staged changes or only at certain files.
  3. Choose the most accurate type, and do not split it into multiple types just to appear complete.
  4. Choose a short scope, preferring the business domain, module name, configuration domain, or main class name.
  5. Write a one-line title in Chinese explaining what this commit accomplishes, without a period.
  6. If the changes exceed one point, add a blank line and a Chinese body list starting with - .
  7. First return the complete commit document directly, and clearly ask the user whether to commit with this version.
  8. If the user confirms, directly use this version of the text to perform the commit.
  9. If the user is dissatisfied and provides a manually revised version, by default use the user-provided version as the final text, then do one more commit confirmation; after confirmation, perform the commit using the user's version.
  10. Do not wrap the commit message in a Markdown code block unless the user explicitly requests output as a code block.

Interaction Flow

Execute in the following order, without skipping steps:

  1. Read all uncommitted code and determine the main theme of the changes.
  2. Directly produce a complete commit document, without first asking the user "should I write one first."
  3. Append a short confirmation after the commit document, for example "Commit with this version?".
  4. If the user replies with confirm, commit, okay, or just like this, use that text to execute git commit。
  5. If the user explicitly modifies the title or body, treat it as the user overriding the text; restate or directly adopt the user's version, and do only one more confirmation.
  6. After the user's second confirmation, use the user's version to execute git commit。
  7. If the current directory is not a git repository, there are no uncommitted changes, or git commit fails, directly state the specific reason, and do not fabricate the commit result.

Default handling during the confirmation stage:

  • When the user only says "use my version" or provides a new piece of text, do not rewrite it into your own version again, unless the user explicitly asks you to polish it.
  • When the user modifies only part of it, merge the remaining parts with the original text into a complete commit message, then confirm once more.
  • Before actually executing git commit , do not claim "committed" or output a conclusion that the commit succeeded.

Subject Format

Standard title format:

type(scope): 中文概述

Example:

feat(crm): 添加自建SCRM平台集成支持
fix(user-order): 修正平台判断逻辑与查询条件空值校验
refactor(crm): 将CRM推送开关配置改为系统配置服务
perf(mq): 提高写作批改消息队列并发处理能力
chore(git): 添加 IntelliJ IDEA 配置文件到 .gitignore
config(database): 更新数据库连接地址

Title rules:

  • Use a half-width colon and one space:): 。
  • type use lowercase English,scope prefer lowercase English or kebab-case.
  • Use Chinese for the title body, while allowing English originals such as product names, protocol names, class names, and configuration names to be retained.
  • Keep the title within one line, expressing the specific action and object, and avoid vague words.
  • Do not use 修改docker、111、init、refeat such non-searchable, non-auditable titles.
  • Do not add Markdown markers before or after the title, for example do not write ``` feat(crm): ...。

Type Selection

Prefer these types:

  • feat: new features, new interfaces, new fields, new business capabilities, new integrations.
  • fix: fix incorrect logic, exceptions, null value issues, configuration errors, query condition errors.
  • refactor: refactor internal structure, extract utilities, migrate services, adjust package paths, and not primarily for adding capabilities or fixing bugs.
  • perf: clear performance optimization, concurrency capability improvement, batch processing optimization, query optimization.
  • chore: maintenance changes such as Git, build, resource files, dependencies, templates, comments, task switches, etc.
  • config: configuration updates such as configuration items, database connections, API credentials, MQ configuration, application switches, etc.; if the project habitually classifies configuration under chore(config), stay consistent with the project's existing style.
  • docs: documentation changes.
  • test: test additions or adjustments.
  • build: build system, packaging, Dockerfile, CI configuration changes; if the project convention uses chore(build), prefer to follow the project convention.

Selection rules:

  • User-visible capability added, choose feat。
  • Behavior error corrected, choose fix。
  • Code organization improved but external behavior unchanged, choose refactor。
  • Performance metrics, concurrency capability, memory pressure, query efficiency improved, choose perf。
  • Only engineering configuration or metadata maintained, choose chore、config or build。

Scope Selection

scope should be short, stable, and searchable. Priority order:

  1. Business domain:crm、speaking、writing、vip、course、order、batch。
  2. Functional domain:class-hour、speaking-questions、refuel-bag、user-order、oss-domain。
  3. Technical domain:mq、database、config、build、git、quartz、mapper、controller。
  4. Main class name or component name: when the change is concentrated in a single class, utility, or policy, the existing naming may be used, for example smarterDictationRecord、VipPriceValidatorStrategy。

Rules to avoid:

  • Do not write scope as a complete sentence.
  • Do not use an overly broad scope, for example project、code、java, unless the commit truly spans the entire project.
  • Do not stack multiple scopes for one commit; choose the one that best represents the main change.

Body Format

Body format:

type(scope): 中文概述

- 说明第一个关键变更
- 说明第二个关键变更
- 说明验证、迁移或风险点（如适用）

Body rules:

  • Each item starts with - , using Chinese to describe the specific action and impact.
  • Each item should focus as much as possible on "what was changed" and "why it is valuable"; do not mechanically list file by file.
  • 3 to 8 items is usually enough; small commits may include only the title.
  • If configuration, data migration, interface semantics, asynchronous tasks, locks, MQ, or external platforms are involved, the key impact points should be listed in the body.
  • If there are breaking changes, explicitly write BREAKING CHANGE: ...in the body, and explain the migration action.

Example:

feat(crm): 添加自建SCRM平台集成支持

- 引入 SelfScrmApiClient 实现客户匹配与同步接口调用
- 在 CrmPushOrchestrator 中增加 SCRM 平台独立推送流程
- 添加用户资料到 SCRM 请求结构的转换逻辑
- 区分 SCRM 与其他 CRM 平台的同步策略，避免单个平台失败影响整体流程

Output Rules

When the user asks to "write commit documentation" or "write a commit message", the default action is not to only explain the rules, but to first directly output a version of the commit message based on the uncommitted code, and ask whether to commit.

When the user confirms the commit, use the confirmed wording to execute git commit. If the user provides a manually modified version, prefer the user's version, confirm once more, and then execute.

Only when the user explicitly asks for "specifications", "templates", "rules", or "documentation" rather than generating content for the current changes, output the rules instead of generating a single commit message.

When performing a commit, prefer using a non-interactive method to pass the complete commit message, avoiding opening an editor. When the body has multiple lines, ensure that the title and body format are fully preserved.

If the existing project style conflicts with this specification, prioritize following the most recent high-quality commit style in the current repository, and explain the trade-off.