commit-batch

name	Commit: Batch
description	{{ 𝚫𝚫𝚫 }} Split uncommitted changes into granular commits.
when_to_use	When several unrelated changes have piled up uncommitted and a single commit would bundle them — split into one logical commit per change.
model	haiku
effort	low
disable-model-invocation	true
allowed-tools	["Bash(git:*)"]

Current state

git status --short
git diff --stat HEAD

Steps

1. The current state above was captured at invocation; run git diff HEAD on specific files only where the stat alone can't tell you what a change is.
2. Analyse the changes and group them into logical commit units — each group should represent a single coherent change (e.g. one feature, one fix, one refactor).
3. Present the proposed commit plan as a numbered list:
   • Group name / files involved
   • Suggested commit message (conventional commits format)
4. Await approval — stop here and do not proceed until the user responds:
   • If approved, execute commits sequentially. For each group:
     1. Stage only the files listed for that group (git add <files>)
     2. Commit with the proposed message
     3. Confirm success before moving to the next group
   • If changes requested, revise the plan and repeat from step 3.
5. After all commits, push to upstream.

Grouping Guidelines

• Prefer smaller, atomic commits over large ones
• Keep unrelated changes in separate commits even if they touch the same area
• Config/dependency changes separate from feature code
• Test changes alongside the code they test (same commit), unless the test is independent
• Generated files (lockfiles, build artefacts) get their own commit if significant

- Subject line: imperative mood, lowercase, no period, max 50 chars (`add feature` not `added feature` or `adds feature`) - Body: explain *what* and *why*, not *how*; wrap at 72 chars