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

Files of Commit work

davila7/main1 file shown
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)

  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 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.md if helpful.
  7. Run the smallest relevant verification
    • Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on.
  8. 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---
2name: commit-work
3description: "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
9Make 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)
201) Inspect the working tree before staging
21 - `git status`
22 - `git diff` (unstaged)
23 - If many changes: `git diff --stat`
242) 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.
273) 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>`
304) 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
365) 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.
396) 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.
477) Run the smallest relevant verification
48 - Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on.
498) Repeat for the next commit until the working tree is clean
50 
51## Deliverable
52Provide:
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