commit-message

name	commit-message
description	Git commit message conventions: structure, formatting, scoping, body content, breaking changes, trailers. Invoke whenever task involves any interaction with commit messages — writing, reviewing, validating, or understanding message format.
user-invocable	false

Commit Message Format

These rules apply **only to git commit messages**. Do not apply line length limits, formatting conventions, or structure requirements from this skill to other files (code, documentation, configs, etc.).

A good commit message is a patch note read by colleagues, QA, and future you.

Before writing, imagine: - You're writing a patch note for users - You're writing a task for QA to verify - Someone will read this at 3am debugging production

What Makes a Good Message

The best commit messages draw from three sources:

• The task — what problem was being solved
• The implementation context — why this approach was chosen
• The deliverable — what was actually built

When all three are available, use them. The code shows WHAT exists; context reveals WHY. When context is incomplete, describe what you can verify from the code and available information.

Factual, Not Promotional

Commit messages are **factual records**, not marketing copy.

Subject line: Strictly factual. Imperative mood. No judgment. Describes what was done, not how good it is.

Body: Can explain reasoning and trade-offs, but remains objective. Avoid promotional language.

The subject answers: "What did this commit do?" Not: "Why is this commit amazing?"

Structure

``` [scope] subject

body

trailers

``` ``` Key-Name: value Another-Key: value with spaces ``` - All trailers use Title-Case keys - Keep values on single line when possible - Multiple values: use comma-separated or multiple trailers When amending a commit (`git commit --amend`), **rewrite the message as if the commit is new**. **Never add references indicating AI involvement:** ## Core Principles