git-commit-convention

Original：🇨🇳 Chinese

Translated

Use when the user asks to create, revise, or execute a Git commit. Generates an accurate Conventional Commit message and only stages or commits files when explicitly requested.

1installs

Sourcekingstar718/my-skills

Added on2026-10-22

NPX Install

npx skill4agent add kingstar718/my-skills git-commit-convention

SKILL.md Content (Chinese)

View Translation Comparison →

Git Commit Guidelines

Workflow

If the user only asks to generate or revise a commit message: inspect the relevant diff and return the message without staging or committing anything.
If the user explicitly requests a commit: inspect, stage, and commit the changes according to the workflow below.

Do not treat a request to “generate a commit message” as authorization to execute the commit.

Execution Workflow

Run
```
git status --short
```
and inspect the relevant worktree diff and
```
git diff --cached
```
.
Clearly determine which files should be included in the commit and ensure that the message describes only those changes.
If there is already staged content unrelated to the current task, leave it unchanged and stop before committing. Ask the user to decide whether to include it in the same commit or split it first.
Only when the user explicitly requests a commit, stage files individually using
```
git add <target file>
```
. Do not use
```
git add -A
```
or
```
git add .
```
.
Check
```
git diff --cached
```
again. After confirming that the staged content matches the message, execute
```
git commit
```
.
Return the commit hash and title. If the commit fails, return the original error and actionable suggestions for resolving it.

Unless explicitly requested by the user, do not execute

git commit --amend

,

git push

, or use

--no-verify

to bypass hooks.

Message Format

The title must follow

<type>: <subject>

and should not include a scope by default. Add

<type>(scope): <subject>

only when the same change needs to clearly distinguish between modules, such as when it involves frontend, backend, and CI changes simultaneously.

type	Use case
feat	New features or functionality
fix	Bug fixes
docs	Documentation changes
refactor	Refactoring that neither changes functionality nor fixes a bug
chore	Build, dependency, configuration, and other miscellaneous changes
test	Adding or modifying tests
style	Formatting changes that do not affect logic
perf	Performance optimizations

The subject should use Chinese by default, while

type

must remain in English. Use another language only when explicitly requested by the user. Use a single-line commit by default: end the message immediately after the title without adding a body, and therefore without a blank line. Add a concise Chinese bulleted body only when the user explicitly requests an explanation or when multiple key changes genuinely need to be documented. Never invent content that is not present in the diff.

Commit Granularity

By default, combine the same logical change—such as a single bug fix or a multi-file adjustment for one feature—into one commit rather than creating incremental commits for each step.
For unpushed commits with the same topic, you may recommend combining them with
```
git commit --amend
```
. The user must still confirm before execution.
When the user explicitly requests separate commits, follow the user's instructions.

AI Usage Information (Optional)

By default, do not add any AI-related footer, keeping the commit message concise. Only when the user explicitly requests AI attribution, append the following line to the message:

text

AI-Generated-By: <Agent 名称及版本> / <模型>

Determine the information from the current session or active configuration. If it cannot be obtained reliably, use

unknown

. Because Git's Author identity already uses the username and email configured for the repository, do not add

Co-Authored-By

or repeat the Git user identity.