conventional-commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Generate Conventional Commit messages from staged Git context

从暂存的 Git 上下文生成 Conventional Commit 消息

Use this skill to draft a Conventional Commit message from the current staged changes or provided Git context such as

git status

, staged file lists, and

git diff --cached

output.

使用此 skill 根据当前暂存更改或提供的 Git 上下文（如

git status

、暂存文件列表和

git diff --cached

输出）起草 Conventional Commit 消息。

When to Use This Skill

何时使用此 Skill

User asks for a commit message
User asks for a Conventional Commit
User provides staged Git context
User wants help choosing the correct Conventional Commit type

用户要求提供提交消息
用户要求生成 Conventional Commit
用户提供暂存的 Git 上下文
用户希望帮助选择正确的 Conventional Commit 类型

Repository Workflow

仓库工作流

When repository access is available, run these commands in order at the start of every invocation, even if the skill already ran in the same session:

bash

PAGER=cat git status
PAGER=cat git diff --cached
PAGER=cat git log --author="$(git config user.name)" --pretty=format:'%s' --no-merges -30

Treat
```
git diff --cached
```
as the source of truth. Use status and history only as context; never include unstaged or untracked changes in the message.
If the staged diff is empty, stop and ask whether the user wants to stage files or inspect a different diff target. Do not draft a commit message.
If repository access is unavailable, use provided staged-change context. Ask for that context when none is available.
Use recent authored subjects to match the user's established style and scope conventions without overriding this skill's rules.

当可以访问仓库时，每次调用开始时都应按顺序运行以下命令，即使该 skill 已在同一会话中运行过：

bash

PAGER=cat git status
PAGER=cat git diff --cached
PAGER=cat git log --author="$(git config user.name)" --pretty=format:'%s' --no-merges -30

将
```
git diff --cached
```
视为事实来源。仅将 status 和历史记录作为上下文使用；切勿在消息中包含未暂存或未跟踪的更改。
如果暂存的 diff 为空，请停止并询问用户是希望暂存文件还是检查其他 diff 目标。不要起草提交消息。
如果无法访问仓库，请使用提供的暂存更改上下文。当未提供任何上下文时，向用户询问。
使用最近由当前作者创建的提交主题来匹配用户既定的风格和 scope 约定，但不得覆盖此 skill 的规则。

Commit Type Rules

提交类型规则

Choose one of these types:

```
feat
```
— introduces a new feature
```
fix
```
— patches a bug
```
docs
```
— documentation only
```
style
```
— formatting or non-semantic code style changes
```
refactor
```
— code restructuring without bug fix or new feature
```
perf
```
— performance improvement
```
test
```
— add or correct tests
```
build
```
— build system or dependency changes
```
ci
```
— CI configuration or workflow changes

Never use

chore

— pick the most specific type from the list above instead.

Use an optional scope when it improves clarity. Never use multiple scopes in a single commit; if a change spans areas, pick the primary one or omit the scope. You can use

git log <file>

to see past scopes used for a file or directory.

从以下类型中选择一个：

```
feat
```
— 引入新功能
```
fix
```
— 修复 bug
```
docs
```
— 仅修改文档
```
style
```
— 格式调整或不影响语义的代码样式更改
```
refactor
```
— 在不修复 bug 或添加新功能的情况下重构代码
```
perf
```
— 性能改进
```
test
```
— 添加或修正测试
```
build
```
— 构建系统或依赖项更改
```
ci
```
— CI 配置或工作流更改

切勿使用

chore

— 请从上述列表中选择最具体的类型。

可以使用可选的 scope 来提高清晰度。单次提交中切勿使用多个 scope；如果更改涉及多个领域，请选择主要领域或省略 scope。可以使用

git log <file>

查看过去对某个文件或目录使用的 scope。

Drafting Rules

起草规则

Base the message on the current staged diff or provided staged-change context.
If the staged diff is ambiguous, read repository files only as needed to clarify intent.
Prefer a single commit message that captures the primary reason for the staged changes.
Use imperative mood.
Keep the subject under 72 characters.
Add a body only when the subject alone is not enough.
- If you add a body, use markdown lists if it helps readability.
Add a footer only for breaking changes or issue references.
When a message can be drafted, do not output explanation, reasoning, or commentary. Output only the final commit message.
Beware of pagination in git and GitHub cli, set
```
PAGER=cat
```
and
```
GH_PAGER=cat
```
.

根据当前暂存 diff 或提供的暂存更改上下文编写消息。
如果暂存 diff 含义不明确，仅按需读取仓库文件以明确意图。
优先使用一条能够概括暂存更改主要目的的提交消息。
使用祈使语气。
主题行保持在 72 个字符以内。
仅当主题行不足以说明情况时添加正文。
- 如果添加正文，可以使用 Markdown 列表来提高可读性。
仅在出现破坏性变更或问题引用时添加 footer。
能够起草消息时，不要输出解释、推理或评论。仅输出最终提交消息。
注意 Git 和 GitHub CLI 的分页设置，使用
```
PAGER=cat
```
和
```
GH_PAGER=cat
```
。

Output Rules

输出规则

Output only the complete commit message as plain text:

no Markdown fences
no labels
no commentary

Format:

<type>(<scope>): <description>

<type>: <description>

Optional body and footer may follow standard Git commit message formatting.

仅以纯文本形式输出完整的提交消息：

不使用 Markdown 围栏
不添加标签
不添加评论

格式：

<type>(<scope>): <description>

或

<type>: <description>

可选的正文和 footer 可以遵循标准 Git 提交消息格式。

Gotchas

注意事项

Always base the message on the current staged-change context, not unstaged or hypothetical changes.
Prefer one primary purpose when multiple files are staged. Do not list every file in the subject line.
Do not treat formatting or dependency updates as
```
feat
```
or
```
fix
```
unless the context clearly shows that.
Use
build
for dependency or build tooling changes.
Use
ci
for workflow and pipeline changes.
Use
refactor
for restructuring that does not change behavior.
Only use
!
or
BREAKING CHANGE:
when the change is actually breaking.

始终根据当前暂存更改上下文编写消息，而不是未暂存或假设中的更改。
当暂存多个文件时，优先选择一个主要目的。不要在主题行列出每个文件。
除非上下文明确显示，否则不要将格式调整或依赖项更新视为
```
feat
```
或
```
fix
```
。
对依赖项或构建工具更改使用 build。
对工作流和流水线更改使用 ci。
对不改变行为的重构使用 refactor。
仅当更改确实具有破坏性时，才使用 ! 或 BREAKING CHANGE:。

Troubleshooting

故障排查

Issue	Solution
The diff looks too large or mixed	Focus on the primary purpose of the staged changes and use the body for important secondary details.
The type is unclear from the diff alone	Read only the relevant repository files needed to clarify the intent.
The output is too verbose	Return only the final commit message, with no explanation.

问题	解决方案
diff 过大或涉及内容混杂	聚焦暂存更改的主要目的，并使用正文说明重要的次要细节。
仅凭 diff 无法确定类型	仅读取明确意图所需的相关仓库文件。
输出过于冗长	仅返回最终提交消息，不添加任何解释。

References

参考资料

Conventional Commits

Conventional Commits