commit-batching

You are about to commit. Do **not** `git add -A && git commit` the whole tree at once. Group the pending changes into logical, single-concern commits first. ## Current working tree ```! git status --short 2>/dev/null || echo "(not a git repo)" echo "--- branch ---"; git rev-parse --abbrev-ref HEAD 2>/dev/null || true echo "--- staged/unstaged stat ---"; git diff --stat HEAD 2>/dev/null || true echo "--- untracked ---"; git ls-files --others --exclude-standard 2>/dev/null || true ``` ## Method 1. **Survey** — run `git status` (staged, unstaged, *and* untracked) and read enough of `git diff` to understand each change's intent. Never stage what you haven't looked at. 2. **Plan** — group changed paths into single-concern batches and draft a one-line message for each. Present the plan as a compact list *before* executing. 3. **Execute per group** — `git add <explicit paths>` → confirm `git diff --cached --stat` matches the intended group → commit with a focused message. Repeat for the next group. 4. **Verify tree** — after the loop, `git status` should be clean (or leave only paths you deliberately chose not to commit). 5. **Push** — only if the original request asked you to push. Respect the repo's branching convention (branch first unless the project says commit straight to main). ## Grouping principles - **One concern per commit.** A feature, a bugfix, a refactor, and a config/dependency bump are separate commits even when touched in the same working session. - **Document...