git-commit

Git Commit

Based on the staged, unstaged, and untracked changes in the current workspace, generate a single git commit that truthfully summarizes the scope of the changes, and execute the commit directly.

Execution Principles

First determine whether the current changes can be honestly summarized as a single commit.
Prefer to use the git status、git diff HEADalready provided by the user, the current branch, and recent commit records; if missing, read them yourself as a supplement.
Unless the user explicitly limits the scope, by default commit all relevant changes in the current workspace, using git add -A。
Do not casually modify code, do not run tests, do not clean up unrelated files, and do not perform extra formatting.
Do not amend, do not split into multiple commits, and do not push, unless the user explicitly requests it.
If there are no committable changes, directly state that a commit cannot be created; do not create an empty commit.
If the changes clearly contain two or more unrelated topics, first point out that they cannot be safely merged into a single commit, rather than fabricating a vague message.

Standard Workflow

1. Gather context

Prefer to consume the git information already given in the user's message.
If the context is incomplete, then run the necessary commands as a supplement:
- git status
- git diff HEAD
- git branch --show-current
- git log --oneline -10

2. Summarize the intent of the changes

Distill the single theme of this commit.
Identify the 2 to 5 most important change points and write them into the commit body.
Prefer to describe the "results" and "behavior changes", not just list file names.

3. Generate the commit message

Use a Conventional Commit prefix for the title, for example:feat、fix、refactor、docs、chore、test、build。
The title must be specific and able to summarize all changes; do not write vague words like "update files".
The body uses Chinese bullet points, each on its own paragraph, and should be written as result descriptions that users can understand as much as possible.

Commit Message Template

Use this structure by default, and keep the blank-line style consistent:

type: 简明概括本次改动

- 改动点 1

- 改动点 2

- 改动点 3

If the change is very small, it is allowed to keep only 1 to 2 bullet points, but do not omit the title.

Execution Constraints

For environments that support tool calls, complete stage and commit in the same reply.
If the user explicitly requests "do not output any text, only output tool calls", strictly comply and do not send extra explanations.
Prefer non-interactive commit methods to ensure that multi-line commit messages can be written reliably.
The default command order is first git add -A, then git commit。
If the user explicitly specifies "only commit staged content" or "only commit certain files", execute according to the user's scope and do not expand the commit scope.

Recommended Command Patterns

When the environment allows a single shell command to complete it, prefer a non-interactive way to write a multi-line message, for example:

git add -A && git commit -F - <<'EOF'
feat: 示例标题

- 要点 1

- 要点 2
EOF

If the tool system supports sending multiple sequential tool calls in one message, you may also execute git add -A and git commitseparately, but do not include extra text.

Examples

Example 1

The user says:

$git-commit 创建一个 git commit：
## Context
- Current git status: !`git status`
- Current git diff (staged and unstaged changes): !`git diff HEAD`
- Current branch: !`git branch --show-current`
- Recent commits: !`git log --oneline -10`

Expected behavior:

Read the current changes and the style of recent commits.
Summarize a single commit theme.
Complete in one reply git add -A and git commit。

Example 2