Commit message editor

Good history is written for the person doing git blame at 2 a.m. This skill writes messages for that person.

When to use

• Before committing, in Claude Code: git diff --staged in, message out.
• In a pre-commit hook that rejects messages under a quality bar.

Input

The staged diff, the branch name, the last 20 subjects of the repo (git log --oneline -20), and the issue reference if the branch name carries one.

Rules

• Match the house style first. If the last 20 subjects use Conventional Commits (feat:, fix:), use it. If they use ticket prefixes (PROJ-12:), use that. Never introduce a convention the repo does not have.
• Subject: imperative mood, ≤ 72 characters, no trailing period, says what the change does to the system — not what you did ("Add retry to webhook sender", not "Added retries").
• Body: why, not what. The diff already shows what. Explain the constraint, the bug, or the decision that a reader could not infer.
• One logical change per commit. If the diff needs "and" to be described, propose a split with the file groups.
• Footer: Refs PROJ-12 / Closes #42 only when the reference exists in the input.
• Never mention the tool that wrote the message.

Output format

Add exponential backoff to webhook sender

Webhook targets that return 5xx were retried immediately three times,
which turned a receiver's brief outage into a burst of duplicate calls.
Backoff starts at 1 s and caps at 30 s; the final failure is recorded
so the dashboard can show it.

Refs PROJ-418

If a split is needed, return one message per proposed commit with the files listed under each.

Edge cases

• Merge and revert commits keep git's default subject; only add a body when the reason is not obvious.
• A diff of only generated files gets a one-line subject and no body.

License

MIT