commitlisted

# Commit Turn the current working tree into one or more commits: group changes by intent, draft a [Conventional Commits](https://www.conventionalcommits.org/) message per group, get your review, then apply. ## 1. Inspect the full tree Re-derive the picture from scratch every time: `git status`, `git diff`, and `git diff --staged` together. Never treat whatever happens to already be staged as correct; re-plan the grouping from the full tree regardless of the current index. A freshly initialized repo has no commits yet (an unborn branch): `git log` fails on it instead of returning empty. Check for this up front rather than letting a downstream `git log` call error out. ## 2. Group by intent Each group becomes exactly one commit. A group is everything that serves one purpose: - Don't split one logical change across commits just because it touches several files. - Don't merge unrelated purposes into one commit just because they touch the same file: split at the hunk level (`git add -p`, or write and apply a partial patch) when a single file mixes two intents. - If the whole tree really is one intent, one commit is the correct output. Grouping doesn't mean forcing a split that isn't there. - Where changes have a dependency order (a refactor a following feature builds on), commit them in that order. Check `git log` for this repo's own convention around the `type(scope):` scope, and match it unless a scope clearly earns its place. If there's no history yet to learn from, def