commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Commit

提交

Use this skill to turn the requested changes into one or more clean commits without absorbing unrelated work.

使用此技能将请求的变更转换为一个或多个清晰的提交，不包含无关工作。

Scope

适用范围

Default: commit only changes made by the current agent in the current task. Determine ownership from the known starting state, conversation, and tool history; do not infer it merely from the current diff or file path.
All changes: inspect and commit the whole working tree only when the user explicitly asks to commit all, everything, or the whole tree.
Explicit subset: honor any files, hunks, commits, or exclusions named by the user.
Temporary artifacts: exclude investigation-only diagnostics, logs, traces, profiler output, experimental toggles, screenshots, and repro fixtures unless explicitly requested. Keep permanent regression tests; ask if unclear.
If change ownership or the requested boundary cannot be determined reliably, stop before staging and ask. Never include pre-existing, concurrent, or user-authored changes by guesswork.

默认规则： 仅提交当前任务中当前Agent所做的变更。从已知初始状态、对话记录和工具使用历史判断变更归属；不可仅通过当前diff或文件路径推断归属。
所有变更： 仅当用户明确要求提交全部、所有内容或整个工作区时，才检查并提交完整工作区。
明确子集： 严格遵循用户指定的文件、代码块、提交或排除项要求。
临时产物： 排除仅用于调查的诊断信息、日志、追踪数据、分析器输出、实验性开关、截图和复现环境，除非用户明确要求提交。保留永久回归测试；若不确定则询问用户。
若无法可靠判断变更归属或请求的边界范围，在暂存前停止操作并询问用户。绝不能通过猜测包含已存在的、并发的或用户自行编写的变更。

Approval Modes

审批模式

Direct mode: If the user asks to commit, analyze the requested scope and create the needed commit or commits without asking for a separate "go".
Plan mode: If the user asks for a plan, asks to review commits first, says to wait, says to prompt or ask before committing, or otherwise requests approval first, present a commit plan and wait for explicit approval such as
```
go
```
before staging or committing. After approval, create all agreed commits without asking again unless the working tree changes unexpectedly.
Clarification stop: In any mode, stop before committing if ownership is unclear, mixed hunks cannot be staged safely, repository guidance conflicts with the user's request, or the intended grouping is ambiguous enough that committing would risk losing user intent.
Approval response: If a previous turn presented a commit plan and the user now says
```
go
```
, treat that as approval for that plan. Re-check the working tree before staging.

直接模式： 如果用户要求提交，分析请求的范围并创建所需的提交，无需单独请求“确认”。
计划模式： 如果用户要求制定计划、先审核提交内容、要求等待、要求提交前提示或询问，或明确要求先获得审批，则提交一份提交计划并等待用户明确批准（如
```
go
```
指令）后再进行暂存或提交。获得批准后，创建所有约定的提交，除非工作区意外变更，否则无需再次询问。
澄清暂停： 在任何模式下，若归属不明确、混合代码块无法安全暂存、仓库规范与用户请求冲突，或预期的分组存在歧义导致提交可能丢失用户意图，均需在提交前停止操作。
审批响应： 如果上一轮已提交提交计划且用户现在回复
```
go
```
，则视为批准该计划。暂存前需重新检查工作区状态。

Inspect

检查步骤

Read repository guidance first:
```
AGENTS.md
```
, contribution docs, or visible commit conventions.
Determine whether the work fixes a known GitHub issue from explicit user context, an approved issue/task document, a verified issue URL, or repository metadata. Do not infer an issue relationship from an incidental number alone.
Inspect state with
```
git status -sb
```
,
```
git diff --stat
```
,
```
git diff --staged --stat
```
, and targeted
```
git diff
```
/
```
git diff --staged
```
. Inspect relevant untracked files before staging them.
Classify staged, unstaged, and untracked changes as in or out of scope. Task ownership does not imply inclusion; classify task-created instrumentation and fixtures as permanent or temporary before staging. Treat the full tree as context, not as permission to commit it.
Preserve out-of-scope staged changes. If scoped changes occupy fully owned paths, a path-limited commit may leave unrelated index entries intact; if scoped and unrelated hunks share a path or safe isolation is uncertain, stop and ask rather than unstaging or committing someone else's work.
Respect explicit exclusions, such as debug logs or generated artifacts the user said not to commit. Leave excluded changes unstaged and report them afterward.
If there are no in-scope changes, say so and report any remaining out-of-scope changes without committing them.

首先读取仓库规范：
```
AGENTS.md
```
、贡献文档或可见的提交约定。
根据用户明确提供的上下文、已批准的问题/任务文档、已验证的问题URL或仓库元数据，判断工作是否修复了已知的GitHub问题。不可仅通过偶然出现的数字推断与问题的关联。
使用
```
git status -sb
```
、
```
git diff --stat
```
、
```
git diff --staged --stat
```
以及针对性的
```
git diff
```
/
```
git diff --staged
```
检查状态。暂存前检查相关的未跟踪文件。
将已暂存、未暂存和未跟踪的变更分类为在范围内或范围外。任务归属不意味着必须包含；暂存前需将任务生成的工具代码和环境分类为永久或临时。将完整工作区视为上下文，而非提交权限。
保留范围外的已暂存变更。若范围内变更位于完全归属的路径下，限定路径的提交可保留无关的索引条目；若范围内和无关的代码块共享同一路径或无法确定安全隔离，则停止操作并询问用户，而非取消暂存或提交他人的工作。
遵循明确的排除要求，如用户指定不提交的调试日志或生成产物。保留排除的变更为未暂存状态，并在后续报告。
若没有范围内的变更，需告知用户并报告所有剩余的范围外变更，不执行提交操作。

Group

变更分组

Group the in-scope changes by one coherent concept: feature, fix, refactor, test, docs, config, dependency, or subsystem. Prefer separate commits when changes would be reviewed, reverted, or explained independently.

If a file contains unrelated changes, split by hunk with

git add -p

or another path/hunk-limited staging method. Do not put unrelated hunks in one commit just because they share a file.

将范围内的变更按一个连贯的概念分组：功能、修复、重构、测试、文档、配置、依赖或子系统。当变更需要独立审核、回退或解释时，优先拆分为单独的提交。

若一个文件包含无关变更，使用

git add -p

或其他限定路径/代码块的暂存方法拆分。不可仅因共享同一文件就将无关代码块放入同一个提交。

Message Style

提交消息格式

Follow explicit user instructions and repository or workspace guidance when present; they override this skill's defaults. Otherwise use this default:

Conventional Commit
```
type: subject
```
no scope parentheses
imperative, concrete subject
no trailing period
no
```
Co-authored-by
```
trailer unless the user explicitly asks
when the commit fixes a verified GitHub issue, append
```
 #<number>
```
to the end of the subject

Use the issue suffix only when the commit is intended to fix that issue, not merely when it is related or discovered during investigation. For multiple explicitly fixed issues, append each verified reference at the end. Repository-specific message rules or explicit user instructions still take precedence.

Good:

text

fix: preserve scroll offset after prepend
fix: preserve failed CRUD creates #547
feat: add commit planning skill
docs: document skills install flow

Avoid:

text

fix(list): preserve scroll offset
update stuff
chore: misc.

When the work explicitly fixes issue #547,

fix: preserve failed CRUD creates

is also incomplete because it omits the verified issue suffix.

Use a body for behavioral changes when the reason, invariant, or validation would not be obvious from the title.

若存在明确的用户指令或仓库/工作区规范，优先遵循这些要求；它们将覆盖此技能的默认规则。否则使用以下默认格式：

符合Conventional Commit规范的
```
type: subject
```
格式
不使用范围括号
主语使用祈使语气、具体明确
末尾无句号
除非用户明确要求，否则不添加
```
Co-authored-by
```
标记
当提交用于修复已验证的GitHub问题时，在主语末尾追加
```
 #<number>
```

仅当提交旨在修复该问题时才使用问题后缀，而非仅关联或在调查过程中发现该问题。若明确修复多个问题，追加每个已验证的引用。仓库特定的消息规则或明确的用户指令仍优先适用。

正确示例：

text

fix: preserve scroll offset after prepend
fix: preserve failed CRUD creates #547
feat: add commit planning skill
docs: document skills install flow

避免示例：

text

fix(list): preserve scroll offset
update stuff
chore: misc.

当工作明确修复问题#547时，

fix: preserve failed CRUD creates

也不完整，因为它遗漏了已验证的问题后缀。

当行为变更的原因、不变量或验证逻辑无法从标题中明确体现时，需添加提交正文说明。

Plan Output

提交计划输出

When plan mode is active, present:

text

Proposed commits (N):
1. type: concrete subject
   Rationale: Why this group belongs together.
   Files: path/a, path/b

Then ask for

go

or edits. Do not stage or commit until the user approves.

In direct mode, do this planning internally. Only show a concise summary before or while committing if it helps the user follow a multi-commit split.

当计划模式激活时，呈现如下内容：

text

Proposed commits (N):
1. type: concrete subject
   Rationale: Why this group belongs together.
   Files: path/a, path/b

然后请求用户回复

go

或进行修改。在用户批准前不进行暂存或提交。

在直接模式下，此计划流程在内部完成。仅当有助于用户跟踪多提交拆分时，才在提交前或提交过程中显示简洁的摘要。

Commit

执行提交

For each group:

Stage only that group using path-limited or hunk-limited staging. Do not silently unstage out-of-scope changes.
Verify the intended commit contains only that group with
```
git diff --staged --stat
```
, targeted
```
git diff --staged
```
, and
```
git diff --staged --check
```
. When unrelated index entries remain, use a path-limited commit only for fully owned paths and verify those paths separately.
Commit with the agreed message.
Re-check the tree after hooks run, then continue to the next group.

After all commits, report commit hashes and any remaining unstaged files. If a commit fails, stop and report the exact failure and the current git state.

针对每个分组：

使用限定路径或限定代码块的方式仅暂存该分组。不可静默取消范围外变更的暂存状态。
使用
```
git diff --staged --stat
```
、针对性的
```
git diff --staged
```
和
```
git diff --staged --check
```
验证预期提交仅包含该分组。当存在无关的索引条目时，仅对完全归属的路径使用限定路径提交，并单独验证这些路径。
使用约定的消息执行提交。
钩子运行后重新检查工作区，然后继续处理下一个分组。

所有提交完成后，报告提交哈希值和所有剩余的未暂存文件。若提交失败，停止操作并报告确切的失败原因和当前Git状态。