conventional-commit_skill

Overview

This skill generates conventional commit messages that follow the Conventional Commits specification and common best practices. It helps format headers, bodies, scopes, and footers so commits are clear, reviewable, and semantically meaningful. Use it to standardize commit history and enable automated versioning and changelogs.

How this skill works

The skill inspects your change description, affected files, and intended intent (fix, feat, docs, etc.) to produce a properly formatted commit. It enforces header rules (type, optional scope, subject), wraps body lines under 100 characters, and includes footers such as BREAKING CHANGE or revert metadata when requested. It can also suggest branch names matching the chosen type.

When to use it

• When creating a new commit to ensure consistent, machine-readable messages
• When preparing pull requests or changelogs that rely on semantic commit types
• When you need to mark breaking changes for automated major version bumps
• When updating CI, dependencies, or docs and you want standard commit types
• When reverting a previous change and want the proper revert format

Best practices

• Work on feature branches named <type>/<short-description> (e.g., feat/add-login)
• Write the header in imperative present tense, capitalize first letter, no trailing period
• Keep header ≤ 70 characters and wrap body lines under 100 characters
• Use the body to explain what and why, not implementation details
• Add BREAKING CHANGE: in the footer or append ! to type/scope for breaking API changes

Example use cases

• Create a bugfix commit: fix(auth): Prevent token refresh race condition
• Add a new feature with scope: feat(payments): Support Apple Pay tokenization
• Document changes: docs(readme): Update integration guide for v2 API
• Mark breaking API change: feat(api)!: Remove deprecated v1 endpoints with BREAKING CHANGE footer
• Revert a faulty commit using the revert format including reason and original commit header