Write commit messages from a staged diff in Conventional Commits 1.0.0 format – correct type and scope, `!` and BREAKING CHANGE footers, GitHub closing keywords, and a body that explains why – and split mixed changes into separately revertable commits.
Write commit messages from a staged diff in Conventional Commits 1.0.0 format - correct type and scope, `!` and BREAKING CHANGE footers, GitHub closing keywords, and a body that explains why - and split mixed changes into separately revertable commits. Use when someone asks "write a commit message for this diff", "commit this", "is this a breaking change?", or "split this into proper commits". Do NOT use for the pull request description - use pr-description-writer instead - or for turning a release's commits into a CHANGELOG.md - use changelog-generator instead.This is the skill's description: the text your AI reads to decide when the skill applies.
git-commit-writer/SKILL.md
---
name: Git Commit Writer
description: Write commit messages from a staged diff in Conventional Commits 1.0.0 format - correct type and scope, `!` and BREAKING CHANGE footers, GitHub closing keywords, and a body that explains why - and split mixed changes into separately revertable commits. Use when someone asks "write a commit message for this diff", "commit this", "is this a breaking change?", or "split this into proper commits". Do NOT use for the pull request description - use pr-description-writer instead - or for turning a release's commits into a CHANGELOG.md - use changelog-generator instead.
---
# Git Commit Writer
A commit message is the only documentation guaranteed to travel with the code: `git blame` surfaces it at the exact line someone is about to change, years after the ticket tracker is gone. The costly mistake this skill prevents is the message that restates the diff ("update user service", "fix bug", "wip") and drops the one thing the diff cannot show - why. A close second is the mixed commit, where a refactor, a fix, and a formatting sweep share one SHA and none can be reverted or bisected alone.
## Operating procedure
### Step 1: Read the actual change, not the file list
Run `git diff --staged` (or `git show <sha>` when rewording) and read every hunk. Collect: what behavior changed, which component owns it, whether a public surface changed (exported API, CLI flag, config key, HTTP contract, schema, event payload), and the motivation. Motivation is rarely in the diff - get it from the user, the issue, or the branch name, and flag it if inferred.
Read `git log --oneline -20` for conventions: Conventional Commits or not, existing scopes, trailers like `Signed-off-by:` (DCO). Match the repo; without Conventional Commits, write a plain imperative subject with the same body discipline.
### Step 2: Decide whether this is one commit or several
One commit means one logical change: you can describe it in a single subject without "and", and reverting it would undo exactly one decision. Split when the staged diff contains any of these:
- A refactor or rename alongside a behavior change - split so the refactor is provably behavior-neutral and the fix is small.
- Formatting or lint autofixes across files the change does not otherwise touch.
- An unrelated fix noticed in passing.
… load the full skill through Skill MeClick to play with sound.