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.