SKILL.md (2634B)
1 --- 2 name: commit-work 3 description: "Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits." 4 --- 5 6 # Commit work 7 8 ## Goal 9 Make commits that are easy to review and safe to ship: 10 - only intended changes are included 11 - commits are logically scoped (split when needed) 12 - commit messages describe what changed and why 13 14 ## Inputs to ask for (if missing) 15 - Single commit or multiple commits? (If unsure: default to multiple small commits when there are unrelated changes.) 16 - Commit style: Conventional Commits are required. 17 - Any rules: max subject length, required scopes. 18 19 ## Workflow (checklist) 20 1) Inspect the working tree before staging 21 - `git status` 22 - `git diff` (unstaged) 23 - If many changes: `git diff --stat` 24 2) Decide commit boundaries (split if needed) 25 - Split by: feature vs refactor, backend vs frontend, formatting vs logic, tests vs prod code, dependency bumps vs behavior changes. 26 - If changes are mixed in one file, plan to use patch staging. 27 3) Stage only what belongs in the next commit 28 - Prefer patch staging for mixed changes: `git add -p` 29 - To unstage a hunk/file: `git restore --staged -p` or `git restore --staged <path>` 30 4) Review what will actually be committed 31 - `git diff --cached` 32 - Sanity checks: 33 - no secrets or tokens 34 - no accidental debug logging 35 - no unrelated formatting churn 36 5) Describe the staged change in 1-2 sentences (before writing the message) 37 - "What changed?" + "Why?" 38 - If you cannot describe it cleanly, the commit is probably too big or mixed; go back to step 2. 39 6) Write the commit message 40 - Use Conventional Commits (required): 41 - `type(scope): short summary` 42 - blank line 43 - body (what/why, not implementation diary) 44 - footer (BREAKING CHANGE) if needed 45 - Prefer a subject line less than 50 characters, never more than 68 (including whitespace) 46 - Prefer an editor for multi-line messages: `git commit -v` 47 - Use `references/commit-message-template.md` if helpful. 48 7) Run the smallest relevant verification 49 - Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on. 50 8) Repeat for the next commit until the working tree is clean 51 52 ## Deliverable 53 Provide: 54 - the final commit message(s) 55 - a short summary per commit (what/why) 56 - the commands used to stage/review (at minimum: `git diff --cached`, plus any tests run)