git-commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git Commit Skill

Git Commit 技能

Available scripts

可用脚本

Script	Purpose
`scripts/repo-discover.sh [start_dir]`	Detect current-repo vs descendant-repo layout
`scripts/repo-status.sh [repo]`	Show branch, status, staged summary, and unstaged summary
`scripts/git-commit.sh [--repo path] "msg" [files...]`	Commit staged or selected files in one repository
`scripts/git-push.sh [--repo path] [--force]`	Push the current branch safely in one repository

</scripts> <objective>

Create one or more Conventional Commits from the current repository state, one per logical change group.
Base every decision on actual git status and diff output.
When multiple logical groups of changes exist, identify each group and commit them separately in sequence.

</objective>

<trigger_conditions>

User intent	Activate
"commit these changes"	yes
"make a git commit"	yes
"/git-commit"	yes
requests that only ask for push/rebase/reset	no, unless commit creation is also requested

</trigger_conditions>

<argument_validation>

If ARGUMENT is missing:

Default to the files, repositories, and logical change units touched in the current session.
Verify the session-derived candidate set against actual
```
git status
```
and
```
git diff
```
output before staging or committing.
If the candidate set contains multiple logical change groups, identify each group and commit them separately in sequence. Do not stop or ask for clarification — iterate through all groups.
If the current session's work is already fully committed, allow the remaining uncommitted changes to become the next candidate set and apply the same grouping logic.

If ARGUMENT is "ALL" or "all":

Take ALL uncommitted changes in the repository, regardless of whether they were touched in the current session.
Group all changes into logical change sets based on related functionality, feature area, or purpose.
Commit each group separately in sequence. Do not stop, do not ask for confirmation, do not skip any files.
Every uncommitted file must be included in exactly one commit group. No file may be left behind.

If ARGUMENT is present (other than ALL):

Treat ARGUMENT as the primary commit target or filter.
Use it to narrow repository discovery, file selection, staging, and commit message generation.
If the filtered set contains multiple logical groups, commit each group separately.
Stop if ARGUMENT does not match the actual repository state.

</argument_validation>

<scope_assumptions>

Start from the current working directory. If it is not a git repository, inspect descendant directories for git repositories before proceeding.
Commit only. Do not push, amend, rebase, or rewrite history unless the user explicitly asks.
After a successful commit, ask whether to push. In Codex, do this with a plain-text confirmation question. In OpenCode, prefer the runtime-native approval prompt when available.
Use Bash commands only.

</scope_assumptions>

Category	Rule
Inspect first	Run `git status --short --branch` before any staging or commit command.
Argument mode	Resolve whether execution is in session-default mode or explicit-argument mode before repository discovery and staging.
Repository discovery	Determine whether the current working directory is a git repository. If not, inspect descendant directories and build a repository list before any `git add` or `git commit` action.
Diff source	If staged changes exist, treat the staged set as the default commit candidate and inspect with `git diff --staged` . If nothing is staged, inspect `git diff` .
Repository boundary	When multiple git repositories are discovered under the current directory, run `git status` , `git add` , and `git commit` inside each repository separately. Never treat multiple repositories as one commit unit.
Logical scope	Each commit covers exactly one logical change. When multiple logical groups exist, identify each group and commit them separately in sequence. Do not stop to ask — iterate through all groups.
Staging discipline	Stage only the files required for the selected logical change. Do not stage everything by default.
Type selection	Choose the Conventional Commit type from the actual dominant change, not from filenames alone.
Scope selection	Use a scope only when one module, package, feature area, or subsystem clearly owns the change. Omit scope when the change spans multiple unrelated areas or the scope would be vague.
Language	Write commit subject and body in Korean. The Conventional Commit `type` and `scope` stay in English (e.g. `feat(auth):` ), but the description after the colon and the body text must be in Korean.
Subject line	Use imperative mood, present tense, lowercase after the colon, and keep the subject under 72 characters.
Body/footer	Add a body only when the subject cannot capture important context. Add footers only for verified issue references, breaking changes, or explicitly requested metadata.
Push confirmation	After `git add` and `git commit` complete successfully, ask whether to run `git push` . In Codex, ask in plain text. In OpenCode, prefer its native ask-style approval prompt when available; otherwise fall back to plain text.
Safety	Never commit secrets, generated credentials, or unrelated user changes. Never use `--no-verify` , force flags, or destructive git commands unless the user explicitly asks.
Failure handling	If hooks fail, inspect the error. Fix and retry only when the failure is directly caused by the current change set and the fix is safe. Otherwise stop and report the blocker.

</required> <forbidden>

Category	Avoid
Staging	`git add .` or blanket staging when unrelated changes exist (exception: ALL mode stages all files but still commits per logical group)
Argument handling	ignoring an explicit ARGUMENT and committing a broader change set than requested
Cherry-picking in ALL mode	skipping files or leaving uncommitted changes behind when ARGUMENT is ALL
Repository boundary	running `git add` or `git commit` from a non-repository root and assuming nested repositories will be included
Push	auto-running `git push` after commit without explicit confirmation
Hooks	`--no-verify` unless the user explicitly requests it
History rewrite	amend, rebase, reset, force push, or other history-editing commands without explicit request
Secrets	committing `.env` , credentials, private keys, or tokens
Guessing	inventing a scope, footer, or grouped change set that is not supported by the diff

</forbidden>

<decision_tables>

脚本	用途
`scripts/repo-discover.sh [start_dir]`	检测当前仓库与子目录仓库的结构
`scripts/repo-status.sh [repo]`	显示分支、状态、暂存摘要和未暂存摘要
`scripts/git-commit.sh [--repo path] "msg" [files...]`	在单个仓库中提交暂存或选定的文件
`scripts/git-push.sh [--repo path] [--force]`	在单个仓库中安全推送当前分支

</scripts> <objective>

根据当前仓库状态创建一个或多个符合Conventional Commits规范的提交，每个逻辑变更组对应一个提交。
所有决策均基于实际的git状态和diff输出。
当存在多个逻辑变更组时，识别每个组并按顺序分别提交。

</objective>

<trigger_conditions>

用户意图	是否激活
"commit these changes"	是
"make a git commit"	是
"/git-commit"	是
仅请求push/rebase/reset的需求	否，除非同时请求创建提交

</trigger_conditions>

<argument_validation>

如果缺少参数：

默认使用当前会话中涉及的文件、仓库和逻辑变更单元。
在暂存或提交前，通过
```
git status
```
和
```
git diff
```
输出验证会话衍生的候选集。
如果候选集包含多个逻辑变更组，识别每个组并按顺序分别提交。无需暂停或请求澄清，遍历所有组。
如果当前会话的工作已完全提交，允许剩余未提交的变更成为下一个候选集，并应用相同的分组逻辑。

如果参数为"ALL"或"all"：

处理仓库中所有未提交的变更，无论是否在当前会话中涉及。
根据相关功能、功能区域或用途将所有变更分组为逻辑变更集。
按顺序分别提交每个组。无需暂停、请求确认或跳过任何文件。
每个未提交的文件必须恰好属于一个提交组，不得遗漏任何文件。

如果参数存在（非ALL）：

将参数视为主要提交目标或筛选条件。
使用它缩小仓库发现、文件选择、暂存和提交信息生成的范围。
如果筛选后的集合包含多个逻辑组，分别提交每个组。
如果参数与实际仓库状态不匹配，则停止操作。

</argument_validation>

<scope_assumptions>

从当前工作目录开始。如果当前目录不是git仓库，在继续之前检查子目录中是否存在git仓库。
仅执行提交操作。除非用户明确要求，否则不执行push、amend、rebase或重写历史的操作。
提交成功后，询问是否推送。在Codex中，使用纯文本确认问题；在OpenCode中，优先使用运行时原生的批准提示（如果可用）。
仅使用Bash命令。

</scope_assumptions>

类别	规则
先检查	在执行任何暂存或提交命令前，运行 `git status --short --branch` 。
参数模式	在仓库发现和暂存前，确定执行是处于会话默认模式还是显式参数模式。
仓库发现	确定当前工作目录是否为git仓库。如果不是，在执行任何 `git add` 或 `git commit` 操作前，检查子目录并构建仓库列表。
Diff源	如果存在暂存变更，将暂存集视为默认提交候选，并使用 `git diff --staged` 检查。如果没有暂存内容，检查 `git diff` 。
仓库边界	当当前目录下发现多个git仓库时，在每个仓库内分别运行 `git status` 、 `git add` 和 `git commit` 。切勿将多个仓库视为一个提交单元。
逻辑范围	每个提交恰好涵盖一个逻辑变更。当存在多个逻辑组时，识别每个组并按顺序分别提交。无需暂停询问，遍历所有组。
暂存规范	仅暂存所选逻辑变更所需的文件。默认情况下不暂存所有内容。
类型选择	根据实际的主导变更选择Conventional Commit类型，而非仅根据文件名。
范围选择	仅当变更明确属于某个模块、包、功能区域或子系统时才使用范围。如果变更跨越多个不相关区域或范围模糊，则省略范围。
语言	提交主题和正文使用韩文。Conventional Commit的 `type` 和 `scope` 保持英文（例如 `feat(auth):` ），但冒号后的描述和正文文本必须使用韩文。
主题行	使用祈使语气、现在时态，冒号后使用小写，主题长度控制在72字符以内。
正文/页脚	仅当主题无法涵盖重要上下文时添加正文。仅在存在已验证的问题引用、破坏性变更或明确请求的元数据时添加页脚。
推送确认	`git add` 和 `git commit` 成功完成后，询问是否运行 `git push` 。在Codex中，使用纯文本提问；在OpenCode中，优先使用其原生的询问式批准提示（如果可用）；否则回退到纯文本提问。
安全性	切勿提交机密信息、生成的凭据或无关的用户变更。除非用户明确要求，否则切勿使用 `--no-verify` 、强制标志或破坏性git命令。
故障处理	如果钩子失败，检查错误。仅当失败由当前变更集直接导致且修复安全时，才修复并重试。否则停止操作并报告障碍。

</required> <forbidden>

类别	禁止操作
暂存	当存在无关变更时，使用 `git add .` 或批量暂存（例外：ALL模式暂存所有文件，但仍按逻辑组提交）
参数处理	忽略显式参数并提交比请求范围更广的变更集
ALL模式下的挑拣	当参数为ALL时，跳过文件或遗留未提交的变更
仓库边界	从非仓库根目录运行 `git add` 或 `git commit` ，并假设嵌套仓库会被包含在内
推送	提交后自动运行 `git push` ，无需显式确认
钩子	除非用户明确要求，否则使用 `--no-verify`
历史重写	未经明确请求，使用amend、rebase、reset、强制推送或其他编辑历史的命令
机密信息	提交 `.env` 、凭据、私钥或令牌
猜测	编造diff不支持的范围、页脚或分组变更集

</forbidden>

<decision_tables>

Argument mode

参数模式

Input state	Action
No ARGUMENT provided	Start from the current session's modified files and repositories, confirm them with git state, group into logical changes, and commit each group separately
No ARGUMENT provided, and current-session work is already committed	If uncommitted changes still remain, allow the remaining uncommitted change set to become the next candidate and apply the same grouping logic
ARGUMENT is "ALL" or "all"	Take ALL uncommitted changes regardless of session, group into logical changes, and commit each group separately — no stopping, no skipping, every file must be committed
ARGUMENT provided (other than ALL) and matches one logical change	Use ARGUMENT as the primary filter for repository discovery, staging, and message generation
ARGUMENT provided (other than ALL) and covers multiple logical groups	Use ARGUMENT as the filter, then group and commit each group separately
ARGUMENT provided (other than ALL) but conflicts with git state	Stop and report the mismatch

输入状态	操作
未提供参数	从当前会话的修改文件和仓库开始，通过git状态确认，分组为逻辑变更，分别提交每个组
未提供参数且当前会话工作已提交	如果仍有未提交的变更，允许剩余未提交的变更集成为下一个候选集，并应用相同的分组逻辑
参数为"ALL"或"all"	处理所有未提交的变更（无论会话范围），分组为逻辑变更，分别提交每个组——不停止、不跳过，所有文件必须提交
参数存在（非ALL）且匹配一个逻辑变更	使用参数作为仓库发现、暂存和信息生成的主要筛选条件
参数存在（非ALL）且涵盖多个逻辑组	使用参数作为筛选条件，然后分组并分别提交每个组
参数存在（非ALL）但与git状态冲突	停止操作并报告不匹配情况

Repository discovery

仓库发现

Observed layout	Action
Current working directory is a git repository	Operate in the current repository and follow the normal commit workflow
Current working directory is not a git repository, but one or more descendant directories are repositories	Build the repository list and run the full commit workflow separately inside each repository that has relevant changes
Current working directory is not a git repository and no descendant repository exists	Stop and report that no git repository was found

观察到的结构	操作
当前工作目录是git仓库	在当前仓库中操作并遵循正常提交流程
当前工作目录不是git仓库，但子目录中有一个或多个仓库	构建仓库列表，并在每个有相关变更的仓库内单独运行完整的提交流程
当前工作目录不是git仓库且没有子仓库	停止操作并报告未找到git仓库

Change-set selection

变更集选择

Repository state	Action
Staged changes only	Commit the staged set.
Staged + unstaged changes, same logical change	Stage the missing files deliberately, then commit the full set.
Staged + unstaged changes, unrelated changes mixed together	Default to the staged set only, or stop if the intended commit target is unclear.
No staged changes, one clear logical change	Stage only the relevant files, then commit.
No staged changes, multiple unrelated changes	Group changes into logical sets. Stage and commit each group separately in sequence.
No diff to commit	Stop and report that there is nothing to commit.

仓库状态	操作
仅存在暂存变更	提交暂存集
暂存+未暂存变更，属于同一逻辑变更	有意暂存缺失的文件，然后提交完整集合
暂存+未暂存变更，混合无关变更	默认仅处理暂存集，或在预期提交目标不明确时停止
无暂存变更，存在一个清晰的逻辑变更	仅暂存相关文件，然后提交
无暂存变更，存在多个无关变更	将变更分组为逻辑集。按顺序分别暂存并提交每个组
无diff可提交	停止操作并报告没有可提交的内容

Type selection

类型选择

Observed dominant change	Type
User-facing capability added	`feat`
Incorrect behavior fixed	`fix`
Docs only	`docs`
Formatting or style only, no behavior change	`style`
Internal restructure without feature or bug fix	`refactor`
Performance improvement	`perf`
Tests added or updated	`test`
Build tooling or dependency management	`build`
CI workflow or automation config	`ci`
Repo maintenance, chores, metadata	`chore`
Reverting an earlier commit	`revert`

观察到的主导变更	类型
添加面向用户的功能	`feat`
修复错误行为	`fix`
仅文档变更	`docs`
仅格式或样式变更，无行为变化	`style`
内部重构，无功能或修复变更	`refactor`
性能优化	`perf`
添加或更新测试	`test`
构建工具或依赖管理	`build`
CI工作流或自动化配置	`ci`
仓库维护、杂务、元数据	`chore`
回滚早期提交	`revert`

Subject/body/footer selection

主题/正文/页脚选择

Condition	Output rule
One-line subject fully explains the change	Subject only
Why, risk, or follow-up matters for reviewers	Add a short body
Breaking API, schema, or behavior change	Use `!` and/or `BREAKING CHANGE:` footer
Verified issue or ticket reference exists	Add `Refs:` or `Closes:` footer
Co-author requested explicitly by the user	Add `Co-authored-by:` footer exactly as requested

</decision_tables>

条件	输出规则
单行主题完全解释变更	仅使用主题
原因、风险或后续事项对评审者很重要	添加简短正文
API、架构或行为的破坏性变更	使用 `!` 和/或 `BREAKING CHANGE:` 页脚
存在已验证的问题或工单引用	添加 `Refs:` 或 `Closes:` 页脚
用户明确请求共同作者	按请求添加 `Co-authored-by:` 页脚

</decision_tables>

Phase 1. Inspect repository state

阶段1. 检查仓库状态

Decide argument mode first:

No ARGUMENT: derive the initial candidate set from the current session's work, then verify it with git state.
No ARGUMENT fallback: if that session-derived set is already fully committed, inspect the remaining uncommitted changes and allow them to become the next candidate set.
ARGUMENT is "ALL" or "all": take ALL uncommitted changes regardless of session scope.
ARGUMENT present (other than ALL): derive the initial candidate set from ARGUMENT, then verify it with git state.

bash

scripts/repo-discover.sh

Then branch by repository layout:

If
```
git rev-parse --show-toplevel
```
succeeds, inspect the current repository:

bash

scripts/repo-status.sh

If the current directory is not a repository but descendant repositories exist, inspect each repository independently:

bash

scripts/repo-status.sh path/to/repo

Do not run one

git add

or one

git commit

from the non-repository root for multiple descendant repositories.

首先确定参数模式：

无参数：从当前会话的工作中导出初始候选集，然后通过git状态验证。
无参数回退：如果会话衍生的集合已完全提交，检查剩余未提交的变更并允许它们成为下一个候选集。
参数为"ALL"或"all"：处理所有未提交的变更，无论会话范围。
参数存在（非ALL）：从参数导出初始候选集，然后通过git状态验证。

bash

scripts/repo-discover.sh

然后根据仓库结构分支处理：

如果
```
git rev-parse --show-toplevel
```
执行成功，检查当前仓库：

bash

scripts/repo-status.sh

如果当前目录不是仓库但存在子仓库，独立检查每个仓库：

bash

scripts/repo-status.sh path/to/repo

切勿从非仓库根目录为多个子仓库运行单次

git add

或

git commit

。

Phase 2. Identify logical change groups

阶段2. 识别逻辑变更组

Analyze the full candidate set and partition it into logical change groups. Each group should contain files that belong to the same feature, fix, module, or purpose.

Grouping heuristics (apply in order):

Files that implement the same feature or fix belong together.
Test files belong with their corresponding implementation files.
Config/build changes related to the same feature belong with that feature.
Unrelated standalone changes each form their own group.

In ALL mode: every uncommitted file must appear in exactly one group. No file may be left behind.

分析完整候选集并将其划分为逻辑变更组。每个组应包含属于同一功能、修复、模块或用途的文件。

分组启发式规则（按顺序应用）：

实现同一功能或修复的文件归为一组。
测试文件与其对应的实现文件归为一组。
与同一功能相关的配置/构建变更归为该功能组。
无关的独立变更各自形成一个组。

在ALL模式下：每个未提交的文件必须恰好出现在一个组中，不得遗漏任何文件。

Phase 3. Stage and commit each group (loop)

阶段3. 暂存并提交每个组（循环）

For each logical group identified in Phase 2, repeat the following:

对于阶段2中识别的每个逻辑组，重复以下步骤：

3a. Stage the group

3a. 暂存组

Use targeted staging commands. Stage only the files in the current group.

bash

git add path/to/file1 path/to/file2
git add -p
git restore --staged path/to/file

使用针对性的暂存命令。仅暂存当前组中的文件。

bash

git add path/to/file1 path/to/file2
git add -p
git restore --staged path/to/file

3b. Generate the commit message for this group

3b. 为该组生成提交信息

Build:

```
type
```
optional
```
scope
```
subject
optional body
optional footer

Message format:

text

<type>[optional scope]: <subject>

[optional body]

[optional footer]

构建：

```
type
```
可选的
```
scope
```
主题
可选的正文
可选的页脚

信息格式：

text

<type>[可选scope]: <主题>

[可选正文]

[可选页脚]

3c. Execute the commit

3c. 执行提交

Subject only:

bash

scripts/git-commit.sh "<type>[scope]: <subject>"
scripts/git-commit.sh --repo path/to/repo "<type>[scope]: <subject>"

Body or footer included:

bash

scripts/git-commit.sh "$(cat <<'EOF'
<type>[scope]: <subject>

<optional body>

<optional footer>
EOF
)"
scripts/git-commit.sh --repo path/to/repo "$(cat <<'EOF'
<type>[scope]: <subject>

<optional body>

<optional footer>
EOF
)"

仅主题：

bash

scripts/git-commit.sh "<type>[scope]: <主题>"
scripts/git-commit.sh --repo path/to/repo "<type>[scope]: <主题>"

包含正文或页脚：

bash

scripts/git-commit.sh "$(cat <<'EOF'
<type>[scope]: <主题>

<可选正文>

<可选页脚>
EOF
)"
scripts/git-commit.sh --repo path/to/repo "$(cat <<'EOF'
<type>[scope]: <主题>

<可选正文>

<可选页脚>
EOF
)"

3d. Continue to next group

3d. 继续下一个组

Move to the next logical group. Repeat 3a–3c until all groups are committed.

Stop within a group only if:

secrets or credential files appear in the candidate set
ARGUMENT (other than ALL) conflicts with the actual modified files or repositories

If multiple descendant repositories are in scope, repeat Phase 2 and Phase 3 inside each repository separately.

移动到下一个逻辑组。重复3a–3c直到所有组都提交完成。

仅在以下情况下在组内停止：

候选集中出现机密或凭据文件
参数（非ALL）与实际修改的文件或仓库冲突

如果多个子仓库在范围内，在每个仓库内分别重复阶段2和阶段3。

Phase 4. Ask whether to push

阶段4. 询问是否推送

After a successful commit, ask for explicit push confirmation.

In Codex: ask a plain-text question such as
```
Commit created. Run git push?
```
In OpenCode: prefer the runtime-native approval prompt rather than assuming a generic Y/N flow
In other runtimes with interactive confirmation UI: use the native confirmation surface when available, but explicit confirmation is still required before push

提交成功后，请求显式的推送确认。

在Codex中：使用纯文本问题，例如
```
提交已创建。是否运行git push？
```
在OpenCode中：优先使用运行时原生的批准提示，而非假设通用的Y/N流程
在其他具有交互式确认UI的运行时中：如果可用，使用原生确认界面，但推送前仍需显式确认

Phase 5. Handle commit failures or push follow-up

阶段5. 处理提交失败或推送后续操作

Failure case	Response
Hook or lint failure caused by current changes	Fix the issue, restage the affected files, and create a new commit attempt
Hook failure unrelated to the current change set	Stop and report the blocker
Empty commit after staging decision	Stop and report that nothing remains to commit
Merge conflict or index lock	Stop and report the repository state
User declines push	Stop after reporting the successful commit
User approves push	Run `scripts/git-push.sh` in the relevant repository, then report the result

</workflow> <examples>

故障情况	响应
当前变更导致钩子或lint失败	修复问题，重新暂存受影响的文件，并尝试创建新提交
钩子失败与当前变更集无关	停止操作并报告障碍
暂存决策后出现空提交	停止操作并报告没有剩余可提交的内容
合并冲突或索引锁定	停止操作并报告仓库状态
用户拒绝推送	报告提交成功后停止操作
用户批准推送	在相关仓库中运行 `scripts/git-push.sh` ，然后报告结果

</workflow> <examples>

Good subjects

良好的主题

```
feat(auth): add passkey login flow
```

fix(cache): prevent stale data when reading projects

docs(cli): document release prerequisites

refactor(worker): split mailbox parsing logic

```
feat(auth): add passkey login flow
```

fix(cache): prevent stale data when reading projects

docs(cli): document release prerequisites

refactor(worker): split mailbox parsing logic

Bad subjects

不良的主题

```
updated stuff
```
```
Fix bug in the API module
```
```
feat: add new feature
```
```
chore(repo): change many things
```

```
updated stuff
```
```
Fix bug in the API module
```
```
feat: add new feature
```
```
chore(repo): change many things
```

Good multiline commit

良好的多行提交

bash

git commit -m "$(cat <<'EOF'
feat(api): filter team memberships

Include only memberships visible to active users in the list response.

Refs: #482
EOF
)"

bash

git commit -m "$(cat <<'EOF'
feat(api): filter team memberships

Include only memberships visible to active users in the list response.

Refs: #482
EOF
)"

Good no-argument handling (single group)

良好的无参数处理（单组）

text

/git-commit

Result:

inspect work done in the current session
confirm the matching repositories and files with git state
all changes belong to one logical group → commit once

text

/git-commit

结果：

检查当前会话中完成的工作
通过git状态确认匹配的仓库和文件
所有变更属于一个逻辑组 → 提交一次

Good no-argument handling (multiple groups)

良好的无参数处理（多组）

text

/git-commit

Result:

inspect work done in the current session
session touched auth module files AND unrelated docs files
group 1: auth module changes →
```
feat(auth): add passkey login flow
```

group 2: docs changes →

docs(cli): document release prerequisites

commit group 1, then commit group 2

text

/git-commit

结果：

检查当前会话中完成的工作
会话涉及auth模块文件和无关的文档文件
组1：auth模块变更 →
```
feat(auth): add passkey login flow
```

组2：文档变更 →

docs(cli): document release prerequisites

先提交组1，然后提交组2

Good no-argument fallback handling

良好的无参数回退处理

text

/git-commit

Result:

detect that the current session's work is already committed
inspect the remaining uncommitted changes
group and commit each remaining logical change

text

/git-commit

结果：

检测到当前会话的工作已提交
检查剩余未提交的变更
分组并提交每个剩余的逻辑变更

Good ALL mode handling

良好的ALL模式处理

text

/git-commit ALL

Result:

take ALL uncommitted changes, regardless of current session
group into logical change sets
commit each group separately — no files left behind

Example output sequence:

bash

scripts/git-commit.sh "feat(auth): add passkey login flow" src/auth/passkey.ts src/auth/passkey.test.ts
scripts/git-commit.sh "fix(cache): prevent stale data when reading projects" src/cache/reader.ts
scripts/git-commit.sh "docs(cli): document release prerequisites" docs/release.md
scripts/git-commit.sh "chore: update dependencies" package.json pnpm-lock.yaml

text

/git-commit ALL

结果：

处理所有未提交的变更，无论当前会话
分组为逻辑变更集
分别提交每个组——无文件遗漏

示例输出序列：

bash

scripts/git-commit.sh "feat(auth): add passkey login flow" src/auth/passkey.ts src/auth/passkey.test.ts
scripts/git-commit.sh "fix(cache): prevent stale data when reading projects" src/cache/reader.ts
scripts/git-commit.sh "docs(cli): document release prerequisites" docs/release.md
scripts/git-commit.sh "chore: update dependencies" package.json pnpm-lock.yaml

Good explicit-argument handling

良好的显式参数处理

text

/git-commit packages/api session validation fix

Result:

treat
```
packages/api session validation fix
```
as the primary target
limit repository discovery and staging to the matching repository and files
generate the commit message from that target

text

/git-commit packages/api session validation fix

结果：

将
```
packages/api session validation fix
```
视为主要目标
将仓库发现和暂存限制在匹配的仓库和文件中
根据该目标生成提交信息

Good post-commit push confirmation

良好的提交后推送确认

text

Commit created. Run git push?

text

提交已创建。是否运行git push？

Good OpenCode push confirmation

良好的OpenCode推送确认

Prefer OpenCode's native ask-style approval prompt when available
If that prompt surface is not available in the current integration, ask in plain text before push

如果可用，优先使用OpenCode的原生询问式批准提示
如果当前集成中该提示界面不可用，推送前使用纯文本询问

Good multi-repository handling

良好的多仓库处理

bash

scripts/git-commit.sh --repo packages/web "fix(web): handle empty session" src/auth.ts
scripts/git-commit.sh --repo packages/api "fix(api): validate session payload" src/routes/session.ts

bash

scripts/git-commit.sh --repo packages/web "fix(web): handle empty session" src/auth.ts
scripts/git-commit.sh --repo packages/api "fix(api): validate session payload" src/routes/session.ts

Bad multi-repository handling

不良的多仓库处理

bash

git add packages/web/src/auth.ts packages/api/src/routes/session.ts
git commit -m "fix: update web and api"

</examples> <validation>

Confirm the repository layout was checked before staging or commit.
Confirm the argument mode was resolved before repository discovery.
Confirm descendant repositories, if any, were handled one repository at a time.
Confirm the final candidate set matches the current session when no ARGUMENT was provided, matches ALL uncommitted changes when ARGUMENT is ALL, or matches ARGUMENT when another ARGUMENT was provided.
Confirm that no-argument mode may fall back to remaining uncommitted changes only after current-session work is already committed.
Confirm that when multiple logical groups exist, each group was committed separately in sequence.
Confirm that in ALL mode, every uncommitted file was included in exactly one commit group with no files left behind.
Confirm each descendant repository received its own
```
git add
```
and
```
git commit
```
sequence.
Confirm
```
git push
```
was not run until explicit confirmation was received.
Confirm each individual commit covers exactly one logical change.
Confirm the final message matches Conventional Commits format.
Confirm the subject is imperative, present tense, and under 72 characters.
Confirm no secret or credential files were included.
Confirm no forbidden flags or history-rewrite commands were used.
Confirm hook failures were handled explicitly instead of bypassed.

</validation>

bash

git add packages/web/src/auth.ts packages/api/src/routes/session.ts
git commit -m "fix: update web and api"

</examples> <validation>

确认在暂存或提交前已检查仓库结构。
确认在仓库发现前已确定参数模式。
确认如果存在子仓库，已逐个处理每个仓库。
确认最终候选集在无参数时匹配当前会话，在参数为ALL时匹配所有未提交变更，在其他参数时匹配参数。
确认无参数模式仅在当前会话工作已提交后，才会回退到剩余未提交的变更。
确认当存在多个逻辑组时，每个组已按顺序分别提交。
确认在ALL模式下，每个未提交的文件已恰好包含在一个提交组中，无文件遗漏。
确认每个子仓库都有自己的
```
git add
```
和
```
git commit
```
序列。
确认在收到显式确认前未运行
```
git push
```
。
确认每个单独的提交恰好涵盖一个逻辑变更。
确认最终信息符合Conventional Commits格式。
确认主题使用祈使语气、现在时态且长度在72字符以内。
确认未包含机密或凭据文件。
确认未使用禁止的标志或重写历史的命令。
确认钩子失败已被显式处理而非绕过。

</validation>