git:20260816.96c9eb7 to git:20260827.8b48dbd

1 added, 1 removed. Audit A to A.

---

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; splits into one logical commit per change."

model: haiku

effort: low

metadata:

glyph: ᚺ

family: commit

disable-model-invocation: false

allowed-tools: ["Bash(git:*)"]

arguments: ["hints"]

argument-hint: "[grouping hints (optional), e.g. 'docs together, config separate']"

---

## Current state

```!

git status --short

- git diff --stat HEAD

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

`type(scope?): description\n\nbody (optional)\n\nBREAKING CHANGE: footer (if applicable)`

</template>

- 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

</conventions>