authoring-commits

majiayu000's avatarfrom majiayu000

Conventional Commits standards for git messages. Use when creating commits, writing commit messages, or reviewing commit history.

⭐0stars🔀0forks📁View on GitHub🕐Updated Jan 5, 2026
[Developer Tools]

When & Why to Use This Skill

This Claude skill streamlines the software development workflow by enforcing the Conventional Commits v1.0.0 standard for Git messages. It assists developers in authoring structured, imperative-style commit messages that clearly distinguish between features, fixes, and breaking changes. By standardizing version control history, it facilitates automated changelog generation, improves team collaboration, and ensures strict adherence to Semantic Versioning (SemVer) principles.

Use Cases

  • Automated Commit Authoring: Quickly generate standardized commit messages for various types of changes including 'feat', 'fix', 'docs', and 'refactor' while maintaining the imperative mood.
  • Breaking Change Management: Correctly identifying and flagging breaking changes using the '!' syntax or footer notes to ensure accurate Semantic Versioning (SemVer) updates.
  • Commit History Auditing: Reviewing and refactoring existing git logs to ensure they meet professional standards and are free from prohibited AI-generated attributions or informal formatting.
  • CI/CD Integration Support: Creating machine-readable commit histories that allow automated tools to parse changes and generate accurate release notes or changelogs.
nameauthoring-commits
descriptionConventional Commits standards for git messages. Use when creating commits, writing commit messages, or reviewing commit history.

Commit Authoring

Write commit messages following Conventional Commits v1.0.0.

Message Structure

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Rules

  1. Prefix with type, optional scope in parentheses, optional ! for breaking changes, colon, space
  2. feat for new features (MINOR in SemVer)
  3. fix for bug fixes (PATCH in SemVer)
  4. Description immediately follows the colon and space
  5. Body separated by one blank line, free-form
  6. Footers one blank line after body, token-separator-value format
  7. Footer tokens use - instead of spaces (except BREAKING CHANGE)
  8. ! before : indicates breaking change; BREAKING CHANGE: footer may be omitted if ! is used
  9. Breaking changes correlate with MAJOR in SemVer

Types

Type Purpose SemVer
feat New feature MINOR
fix Bug fix PATCH
docs Documentation only -
style Formatting, whitespace -
refactor Neither fix nor feature -
perf Performance improvement -
test Adding or updating tests -
build Build system or dependencies -
ci CI configuration -
chore Maintenance tasks -

Description

Use imperative mood: "add feature" not "added feature". Keep under 50 characters. No period. Lowercase after type prefix.

Body

Wrap at 72 characters. Explain what and why, not how.

Prohibited

Do not include "Generated with Claude Code", AI attribution, Co-authored-by lines for AI, emoji, time estimates, dates, or TODO items.

Examples

Simple:

docs: correct spelling of CHANGELOG

With scope:

feat(lang): add Polish language

Breaking change:

feat!: send email to customer when product ships

BREAKING CHANGE: customers now receive emails by default.

With body:

fix: prevent duplicate form submissions

Disables submit button after first click and adds
debounce to the handler.

With footer:

fix: resolve race condition in auth flow

Refs: #123
Reviewed-by: Alice