commit-worklisted

# Commit work ## Goal Make commits that are easy to review and safe to ship: - only intended changes are included - commits are logically scoped (split when needed) - commit messages describe what changed and why ## Inputs to ask for (if missing) - Single commit or multiple commits? (If unsure: default to multiple small commits when there are unrelated changes.) - Commit style: Conventional Commits are required. - Any rules: max subject length, required scopes. ## Workflow (checklist) 1) Inspect the working tree before staging - `git status` - `git diff` (unstaged) - If many changes: `git diff --stat` 2) Decide commit boundaries (split if needed) - Split by: feature vs refactor, backend vs frontend, formatting vs logic, tests vs prod code, dependency bumps vs behavior changes. - If changes are mixed in one file, plan to use patch staging. 3) Stage only what belongs in the next commit - Prefer patch staging for mixed changes: `git add -p` - To unstage a hunk/file: `git restore --staged -p` or `git restore --staged <path>` 4) Review what will actually be committed - `git diff --cached` - Sanity checks: - no secrets or tokens - no accidental debug logging - no unrelated formatting churn 5) Describe the staged change in 1-2 sentences (before writing the message) - "What changed?" + "Why?" - If you cannot describe it cleanly, the commit is probably too big or mixed; go back to step 2. 6) Write the commit message - Use Conventio