Commit: Batch

Current state

git status --short
git rev-parse --verify HEAD >/dev/null 2>&1 && git diff --stat HEAD || echo "(no commits yet, nothing to diff against)"

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). If $hints was given, honour it as the intended grouping; it overrides the guidelines below where they conflict.
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. If git commit exits non-zero and stderr contains commit-msg: lines, read each L<n> <rule>: <excerpt> line, rewrite the message to clear every hit (keeping the meaning) and retry the commit once. If the retry fails too, stop the batch and report the stderr verbatim along with which groups landed and which did not. Never pass --no-verify and never change git config to get past the hook.
     4. Confirm success before moving to the next group
   • If changes requested, revise the plan and repeat from step 3.
5. Report the commits made and stop. Do not push. Publishing is a separate decision from committing; the user pushes, or asks for it explicitly.

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

<template format-reference="https://www.conventionalcommits.org/en/v1.0.0/"> `type(scope?): description\n\nbody (optional)\n\nBREAKING CHANGE: footer (if applicable)` </template> <conventions> - 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 - British spelling, no em dashes, no Oxford commas: the global commit-msg hook rejects all three </conventions>