conventional-commit

To generate conventional commit messages, review your staged git changes, select an allowed type and optional scope, write an imperative description, and apply the final git commit command. This enforces Conventional Commits specification compliance.

A conventional commit message format structures commits with a type, optional scope, imperative description, optional body, and optional footer for breaking changes or issue references. This maintains clear, machine-readable changelogs and semantic versioning signals.

To write a fix or feature commit message, use the corresponding type like fix or feat, add an optional scope such as ui, and provide a short imperative summary. The Skill guides you through composing compliant messages for these common scenarios.

No, this conventional commit workflow does not require commitlint or any external dependencies. It independently provides structured templates, validation for allowed types, and the final git commit command format without additional tooling.

Yes, you can include breaking changes and issue references in a conventional commit. The structured template allows an optional footer section specifically for documenting breaking changes or linking issue references within your git commit.

The best way to standardize git commit messages is applying a structured template aligned with the Conventional Commits specification. This removes ambiguity and inconsistency by enforcing types, optional scopes, and imperative descriptions across all team commits.