git-commit

## What this does Look at everything that has changed in the working tree, decide how the changes should be split into commits, and then create those commits — messages and all — without stopping to ask for approval. The user invoked `/git-commit` because they trust you to make the call, so make it and report what you did afterward. Any argument the user passes is context, not a command: a hint about intent ("addressing review feedback", "this is risky, note the migration") that should inform how you group and what you write. It is never the literal commit message. ## Step 1: Understand what changed Before grouping anything, build a real picture of the diff. Run these together: - `git status` — what's modified, added, deleted, untracked - `git diff` — unstaged changes - `git diff --staged` — anything already staged - `git log --oneline -15` — recent history, to match the tone and see referenced issues/PRs Read the diff to understand the _why_, not just the _what_. You are about to explain these changes to a future reader; you can't do that if you only know which lines moved. If something is genuinely unclear, it's fine to ask one focused question — but usually the diff plus recent history tells the story. If there's nothing to commit, say so and stop. Never create an empty commit. ## Step 2: Decide the grouping — this is the judgment call The goal is **atomic commits**: each commit is one complete, coherent change that stands on its own. The hard part is knowing how ...