Atomic Commit

Create small, reviewable Git commits from local changes when the user explicitly asks for commit creation. Preserve user intent, staged state, and exact user-provided messages.

Invocation Boundary

• Use this skill only when the user explicitly invokes it or asks for atomic commits.
• Never push, pull with rebase, rebase, amend, reset, change history, create branches, create tags, open PRs, or publish anything.
• Never chain into another skill or workflow automatically.
• Stop and report when safe non-interactive grouping is not possible.

Initial Inspection

Start every run with evidence:

1. git status --short --branch
2. Inspect staged, unstaged, and untracked changes separately.
3. Read relevant diffs, file names, binary/generated indicators, and several recent complete commit messages (subject and body). Determine whether HEAD exists; do not infer repository style from a single one-line subject.
4. Identify sensitive, large, binary, generated, lockfile, vendored, or credential-like files before staging.
5. Identify the language used in the user's current conversation or commit request.
6. Report planned groups before committing unless the user supplied an exact grouping that is already safe.

Respect staged intent. Do not silently mix staged and unstaged changes. If staged changes form a coherent commit, keep that boundary. If they are clearly mixed, stop and ask before regrouping; never unstage them automatically.

Grouping Rules

Partition by functional cohesion:

• Keep implementation and its tests together.
• Separate unrelated behavior changes.
• Separate pure refactors from behavior changes when independently deployable.
• Separate mechanical formatting from semantic changes.
• Separate migrations when independently deployable.
• Keep a migration with required supporting code when they cannot work independently.
• Keep generated artifacts out unless the user explicitly expects them and they are part of the deliverable.

If the same file needs hunk-level splitting and there is no safe non-interactive way to stage the right hunks, stop and report the required split instead of risking the index.

Message Rules

Apply this precedence when selecting a commit message:

1. An exact user-provided commit message is authoritative.
2. Otherwise, use the repository's recent commit history as the primary format reference.
3. If the repository has no reachable commits, use the first-commit format below.

For an exact user-provided message:

• Preserve exact messages verbatim.
• Do not rewrite, normalize, prefix, translate, rewrap, or split an exact message.
• One exact full message maps to one commit covering the currently selected changes, even if the skill would otherwise prefer more atomic grouping.
• Ask for additional messages only when the user explicitly requested split commits and did not provide enough exact messages.
• Exact user intent outranks default atomic grouping.

When generating a message from repository history:

• Inspect multiple recent full messages, favoring recent commits that affect the same subsystem or change type.
• Follow the dominant local format for type, scope, subject punctuation, body presence, paragraph or bullet layout, and level of detail.
• Borrow the format, not wording. Never copy an unrelated historical message.
• Use the user's current conversation language for generated <subject> and <body>, even when repository history uses another language. Keep code identifiers, paths, API names, and other technical tokens unchanged when translation would reduce precision.
• Keep Conventional Commit type and scope as concise lowercase English identifiers when the local format uses them.
• If the conversation is multilingual, use the language of the user's latest commit request unless the user specifies another language.

For a repository with no reachable commits, generate the first commit message with this exact structure:

<type>(<scope>): <subject>

<body>

• Use one of these lowercase English types: feat, fix, refactor, perf, test, docs, build, ci, chore, style.
• Choose a concise lowercase English <scope> that identifies the affected subsystem.
• Write <subject> and <body> in the user's current conversation language.
• Separate the subject and body with exactly one blank line.
• Include a meaningful body. Use - bullets when describing multiple changes, and explain what changed with enough detail for later review.

Example for a Chinese conversation:

feat(agent-runtime): 完善隔离执行与审查反馈闭环

- 为 CrewAI Agent 增加角色级输出契约、独立子进程与存储隔离、受限 Planner 选择和真实并行度审计。
- 强制执行上下文预算与 resource_limit 失败分类，统一 Agent、ToolCall、诊断和修复产物的审计语义。
- 将 Review 批准的低风险修复通过 protocol v1 接入确定性 Core Writer，并补充评估脚本、回归测试和架构文档。

Safe Commit Execution

1. Save the current status summary before modifying the index.
2. Stage only files that belong to the next approved group.
3. Avoid destructive index operations. Do not use git reset as a cleanup tool unless the user explicitly authorized that operation.
4. Commit with the exact or selected message.
5. If hooks fail, report the actual error. Do not bypass hooks and do not alter an exact message to appease hooks.
6. After each commit, verify with:
   • git status --short
   • git log -1 --format=fuller
   • git show --stat --oneline --decorate --no-renames HEAD
7. Continue only with remaining groups that are still safe and authorized.

For untracked files, stage by explicit path. Do not use broad git add . when unrelated or sensitive files may exist.

Stop Conditions

Stop and report instead of committing when:

• The user did not explicitly ask to create commits.
• Grouping requires unsafe hunk-level splitting.
• A sensitive, large, binary, generated, or credential-like file needs explicit handling.
• Staged and unstaged changes conflict with the proposed grouping.
• Hooks fail.
• The user explicitly requested split commits but did not provide enough messages or authorize generated messages.

Report Format

Use this structure:

## Planned Groups
- Group: files, message source, reason.

## Executed Commits
- `hash` - exact subject; verification summary.

## Remaining Changes
- Files or groups left uncommitted and why.

## Evidence
- `git status --short --branch` -> summary.
- `git log -1 ...` / `git show ...` -> summary for each commit.

Keep the output specific enough that the user can audit exactly what was committed and what remains.