Conventional Commits

Conventional Commits

Generate a well-formed Conventional Commits message for the currently staged changes.

When to use

When the user asks to write or suggest a commit message, or says "commit this."

Procedure

1. Run git diff --cached to read the staged changes. If nothing is staged, say so and stop.
2. Determine the change type from the diff: feat a new feature, fix a bug fix, docs documentation only, refactor a code change that neither fixes a bug nor adds a feature, test adding or fixing tests, chore tooling or maintenance, perf a performance improvement.
3. Pick a short scope in parentheses when one part of the codebase is clearly affected, for example feat(auth):. Omit the scope if the change is broad.
4. Write the subject line as type(scope): summary. Imperative mood, lower case, no trailing period, under 72 characters.
5. If the change is non-trivial, add a blank line and a short body explaining the what and the why, not the how. Wrap at 72 columns.
6. If anything breaks backward compatibility, add a BREAKING CHANGE: footer describing it.
7. Output only the final commit message, ready to paste.

Example

feat(api): add cursor-based pagination to the users endpoint

Replaces offset pagination, which got slow past 10k rows. Returns a
next_cursor field; pass it back as ?cursor= to page forward.