git-commit（Git 提交）

Git Commit Skill

Available scripts

• 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.

<trigger_conditions>

</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>

<decision_tables>

Argument mode

Repository discovery

Change-set selection

Type selection

Subject/body/footer selection

</decision_tables>

Phase 1. Inspect repository state

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.

scripts/repo-discover.sh

Then branch by repository layout:

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

scripts/repo-status.sh

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

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.

Phase 2. Identify logical change groups

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):

1. Files that implement the same feature or fix belong together.
2. Test files belong with their corresponding implementation files.
3. Config/build changes related to the same feature belong with that feature.
4. 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.

Phase 3. Stage and commit each group (loop)

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

3a. Stage the group

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

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

Build:

1. type
2. optional scope
3. subject
4. optional body
5. optional footer

Message format:

<type>[optional scope]: <subject>

[optional body]

[optional footer]

3c. Execute the commit

Subject only:

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

Body or footer included:

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
)"

3d. Continue to next group

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.

Phase 4. Ask whether to push

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

Phase 5. Handle commit failures or push follow-up

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

Bad subjects

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

Good multiline commit

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)

/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

Good no-argument handling (multiple groups)

/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

Good no-argument fallback handling

/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

Good ALL mode handling

/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:

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

/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

Good post-commit push confirmation

Commit created. Run git push?

Good OpenCode push confirmation

• 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

Good multi-repository handling

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

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

• 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.