conventional-commits_skill

Overview

This skill enforces and explains the Conventional Commits format to produce readable git history and automated changelogs. It helps you write, review, and validate commit messages so releases and tooling can infer semantic versioning. Use it when composing commits, setting up hooks, or generating changelogs.

How this skill works

The skill inspects commit messages for a standardized header: type(scope)?: subject and optional body/footer. It validates type, scope formatting, subject rules (imperative, lowercase, length), and flags breaking changes via ! or BREAKING CHANGE:. It can suggest correct forms, sample messages, and simple regex or commitlint hooks for CI integration.

When to use it

• Creating new git commits to ensure consistent messages
• Reviewing commit history for changelog generation
• Configuring commit hooks (husky/commitlint)
• Preparing release notes or automated changelogs
• Enforcing team commit conventions during code review

Best practices

• Use the defined types (feat, fix, docs, style, refactor, perf, test, chore, ci, revert) consistently
• Keep subject imperative, lowercase first letter, no trailing period, ~50 characters max
• Include scope to clarify affected module or component when relevant
• Add a body to explain why or provide context for non-obvious changes
• Mark breaking changes with ! after the type or with a BREAKING CHANGE: footer
• Link issues/PRs in footers (Closes #123, Refs #456) for traceability

Example use cases

• Commit a new feature: feat(auth): add OAuth2 login
• Fix a bug with context: fix(api): handle null response\n\nPrevent crashes when upstream returns null.\n\nCloses #42
• Document a breaking change: feat(sdk)!: require explicit chain ID in config\n\nBREAKING CHANGE: chainId is now required in SDK init.
• Add a commit hook: .husky/commit-msg runs commitlint to reject invalid messages