commit-style

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Commit Style

提交风格

Rules for writing commits the way this user expects. Applies to every commit, including commits an agent makes on their behalf.

以下是符合用户期望的提交规则，适用于每一次提交，包括Agent代表用户执行的提交。

Format

格式

Conventional Commits — a short

<type>: <title>

, then a blank line, then a concise pointwise body:

<type>: <title>

- point one
- point two

Types:

feat

fix

docs

refactor

perf

test

chore

style

ci

build

revert

采用约定式提交（Conventional Commits）格式——简短的

<type>: <title>

，然后空一行，接着是简洁的要点式正文：

<type>: <title>

- point one
- point two

类型包括：

feat

fix

docs

refactor

perf

test

chore

style

ci

build

revert

。

Title

标题

Short and imperative, lowercase after the colon:
```
feat: add commit-style skill
```
.
Summarizes the logical change, not the files touched.

简短且使用祈使语气，冒号后使用小写字母：
```
feat: add commit-style skill
```
。
总结逻辑变更内容，而非涉及的文件。

Body

正文

Concise, pointwise (bulleted).
Each bullet states one logical point about what changed and why — the overall logic, not implementation minutiae.
Keep it high level; do not enumerate files or over-explain the implementation.
Omit the body only for a trivial single-line change.

简洁、采用要点式（项目符号）。
每个要点说明一项关于变更内容及原因的逻辑要点——聚焦整体逻辑，而非实现细节。
保持高概括性；不要罗列文件或过度解释实现过程。
仅当变更为简单单行内容时可省略正文。

Atomicity and frequency

原子性与提交频率

One commit = one independent, complete logical change. Never commit half a feature or a grab-bag of unrelated edits.
Commit only when an independent logical feature block is complete — no more (too granular), no less (too coarse).
Every commit must be fully self-contained and meaningful when read later in isolation.

一次提交对应一项独立、完整的逻辑变更。绝不要提交未完成的功能或一堆无关的修改。
仅在完成一个独立的逻辑功能模块时提交——既不过于细碎，也不过于粗糙。
每一次提交必须是完全自洽的，且在后续单独查看时具备明确意义。

Anti-patterns

反模式

No
```
phase 1
```
,
```
item 1
```
,
```
part 1
```
,
```
WIP
```
,
```
update files
```
, or checklist-style messages — they are meaningless to anyone reading the history later.
No merging unrelated changes into one commit to save commits.
No deep implementation dumps; keep the message a clear logical summary.

禁止使用
```
phase 1
```
、
```
item 1
```
、
```
part 1
```
、
```
WIP
```
、
```
update files
```
或清单式的提交信息——这些信息对后续查看提交历史的人来说毫无意义。
禁止将无关变更合并到一次提交中以减少提交次数。
禁止堆砌深层实现细节；提交信息应是清晰的逻辑总结。

Procedure

操作流程

Inspect
```
git status
```
,
```
git diff
```
, and
```
git log --oneline
```
before committing.
Stage only the files that belong to this logical change.
Write the message per the rules above, then commit.

提交前检查
```
git status
```
、
```
git diff
```
和
```
git log --oneline
```
。
仅暂存属于本次逻辑变更的文件。
按照上述规则编写提交信息，然后执行提交。

Examples

示例

Good:

feat: add commit-style skill

- Encode the Conventional Commits format with a short title and pointwise body
- Require atomic commits, one per completed logical change
- Document anti-patterns such as phase/item/WIP messages

Bad:

phase 1: item 1 - update files

规范示例：

feat: add commit-style skill

- Encode the Conventional Commits format with a short title and pointwise body
- Require atomic commits, one per completed logical change
- Document anti-patterns such as phase/item/WIP messages

不规范示例：

phase 1: item 1 - update files