Commit work skill
Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits).
by davila7·MIT license·★ 32,299 Stars on the repo·GitHub ↗
Use now
npx degit davila7/claude-code-templates/cli-tool/components/skills/productivity/commit-work#main ~/.claude/skills/commit-workChecked ·commit main
Files of Commit work
SKILL.md
Show the full text56 lines
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)
- Inspect the working tree before staging
git statusgit 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 -porgit restore --staged <path>
- Prefer patch staging for mixed changes:
- 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 summary- blank line
- body (what/why, not implementation diary)
- footer (BREAKING CHANGE) if needed
- Prefer an editor for multi-line messages:
git commit -v - Use
references/commit-message-template.mdif helpful.
- Use Conventional Commits (required):
- Run the smallest relevant verification
- Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on.
- Repeat for the next commit until the working tree is clean
Deliverable
Provide:
- the final commit message(s)
- a short summary per commit (what/why)
- the commands used to stage/review (at minimum:
git diff --cached, plus any tests run)
| 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 an editor for multi-line messages: `git commit -v` |
| 46 | Use `references/commit-message-template.md` if helpful. |
| 47 | 7) Run the smallest relevant verification |
| 48 | Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on. |
| 49 | 8) Repeat for the next commit until the working tree is clean |
| 50 | |
| 51 | ## Deliverable |
| 52 | Provide: |
| 53 | the final commit message(s) |
| 54 | a short summary per commit (what/why) |
| 55 | the commands used to stage/review (at minimum: `git diff --cached`, plus any tests run) |
| 56 |
Discussion
Browse more free Claude skills.