conventional-commits_skill

Overview

This skill enforces and generates Git commit messages that follow the Conventional Commits specification for Aurora projects. It guides the selection of type, scope, subject, body, and footer so commits are consistent, machine-readable, and useful in changelogs. Use it during commit creation, history review, or when validating existing commit messages.

How this skill works

The skill inspects the working tree, staged changes, and recent commit history to determine the appropriate commit type and scope. It suggests an imperative, lowercase subject, optional wrapped body explaining why, and a footer for issue references or breaking changes. It also recommends grouping changes into one logical unit per commit and provides example templates and commands to execute the final git commit.

When to use it

• Creating a new commit or asked to “commit changes”
• Reviewing git status, diffs, or staged files
• Analyzing commit history for consistency or release notes
• After finishing a feature, bug fix, refactor, or tests that need committing
• When the user mentions “conventional commits” or asks about commit format

Best practices

• One logical change per commit; don’t mix unrelated features and fixes
• Choose the correct type (feat, fix, refactor, test, docs, chore, etc.) and include a concise scope
• Write subject in imperative mood, lowercase first letter, no trailing period, ≤120 chars
• Use the body to explain why (wrap at ~72 chars) and the footer for issue IDs or BREAKING CHANGE
• Stage related hunks only (git add -p) and review git diff --staged before committing

Example use cases

• Generate a feature commit: feat(library/book): add publication date validation with body and Closes #234
• Create a bugfix commit with context and bullet points explaining fixes: fix(auth): resolve token refresh race condition
• Refactor commit for non-functional changes: refactor(core): extract validation logic to service
• Write a breaking-change commit with explicit BREAKING CHANGE footer and migration notes
• Separate test commits when tests are added independently: test(book): add unit tests for ISBN validation