commitlisted

# Commit ## Iron Law `COMMIT ONLY THE REVIEWED SLICE. STAGE FILES BY NAME.` Commit packaging is common and should stay lightweight. Load `git-workflow` only when branches, conflicts, rebases, history edits, recovery, or GitHub CLI use are part of the task. ## When to Use - The user asks to commit, stage, split, or package current changes. - You need to group dirty files into one or more logical commits. - You need a right-sized commit subject or body for approved work. ## When NOT to Use - Creating or switching branches, resolving conflicts, rebasing, bisecting, recovering history, deleting branches, or force-pushing. Use `git-workflow`. - Reviewing correctness of the diff. Use `code-review` before packaging non-trivial implementation work. - Preparing release versions, changelogs, tags, or publishing. Use `release` only when requested or approved. ## Core Ideas 1. A branch is not the commit boundary. Even on one branch, group changes by behavior so reviewers can understand what changed and maintainers can revert one behavior without dragging unrelated work with it. 2. Logical commits are reader-facing history. A commit should explain one completed behavior, cleanup, or documentation change; nearby work can wait for a second commit when it would need a different rollback decision. ## Workflow 1. Inspect one compact preflight: `git status --short`, current branch, staged diff stat, unstaged diff stat, and recent log. Stop on unexpected state. 2.