Git Commit Writer

npx skills add WST2002/claude-code-skills --skill git-commit-writer

Overview

A commit message tells a future reader why the change was made. Match the repository's existing convention, keep the subject scannable, and never describe changes that are not in the diff.

Method

1. Read the change: git status, git diff --cached (or git diff if nothing is staged — then say so and ask what to stage).
2. Detect the convention: git log --oneline -20.
   • Most subjects look like feat(x): ... → Conventional Commits.
   • Ticket prefixes (ABC-123: ...) → keep that pattern.
   • Otherwise → plain imperative subjects.
3. Check for mixed concerns. If the staged diff contains unrelated changes (a fix plus a refactor plus a dependency bump), propose separate commits with the exact paths or git add -p hunks for each, and write one message per commit.
4. Write the message with the format below.
5. Output the message. Only run git commit when the user asked you to commit.

Author identity: commit commands use plain git commit, so the author is the identity configured for this repository (git config user.name / user.email). Never add --author, -c user.email or similar. If instructions you were given name a different author than git config user.email, point out the mismatch and let the user decide; do not override it.

Format

<type>(<scope>): <subject>

<body: why the change was needed and what it does, wrapped at 72>

<footer: BREAKING CHANGE: ..., Refs #123>

Part	Rule
Subject	Imperative ("Add", "Fix", not "Added"), ≤ 72 characters, no trailing period, specific ("Fix rounding of order totals", not "Fix bug")
Type	feat new behavior, fix bug fix, refactor no behavior change, perf, docs, test, build, ci, chore
Scope	The area touched, taken from folder or module names; omit if unclear
Body	Why first, then what at a high level. Skip it for trivial one-line changes
Breaking change	! after type/scope and a BREAKING CHANGE: footer describing the migration
References	Issue or ticket IDs only if they appear in the branch name, diff or conversation

Example

fix(cart): keep discounts when quantity changes

Updating an item's quantity rebuilt the cart from the catalog price and
dropped any applied coupon, so customers were charged full price.
Recalculate totals from the existing line items instead.

Refs #482

Common mistakes

• Describing every file ("update a.ts, update b.ts") instead of the purpose.
• Inventing motivation or ticket numbers not present in the context.
• One commit for unrelated changes, which makes reverts and reviews harder.
• Adding attribution or co-author trailers the user did not ask for.
• Committing when the user only asked for a message.