commit-work

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