commit-work

Make commits that are easy to review and safe to ship: Provide: - only intended changes are included - commits are logically scoped (split when needed) - commit messages describe what changed and why - 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. - Inspect the working tree before staging - git status - git diff (unstaged) - If many changes: git diff --stat - 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. - 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 - Review what will actually be committed - git diff --cached - Sanity checks: - no secrets or tokens - no accidental debug logging - no unrelated formatting churn - 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. - Write the commit message - Use Conventional Commits (required): - type(scope): short...