commit

matthew-h-cromer's avatarfrom matthew-h-cromer

Create git commits following conventional commits format. Use when asked to commit changes.

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

When & Why to Use This Skill

This Claude skill automates the creation of Git commits by strictly adhering to the Conventional Commits specification. It streamlines the version control workflow by analyzing staged changes, determining the appropriate commit type (such as feat, fix, or chore), and generating professional, standardized commit messages that improve project maintainability and facilitate automated changelog generation.

Use Cases

  • Standardizing Team Workflows: Enforce a consistent commit message format across a development team to ensure a clean, readable, and searchable project history.
  • Automated Release Management: Facilitate the use of tools like semantic-release by providing structured commit data required for automatic version bumping and release note creation.
  • Improving Code Review Efficiency: Generate descriptive commit messages that focus on the 'why' behind changes, helping reviewers understand the context and intent quickly.
  • CI/CD Integration: Enable automated pipelines to trigger specific build or deployment actions based on the standardized commit types (e.g., triggering a production deploy only on 'feat' or 'fix').
namecommit
descriptionCreate git commits following conventional commits format. Use when asked to commit changes.
allowed-toolsBash, Read, Grep, Glob

Commit Changes

Create commits following the Conventional Commits specification.

Format

<type>(<scope>): <subject>

<body>

Types

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation only
  • style: Formatting, no code change
  • refactor: Code change that neither fixes a bug nor adds feature
  • test: Adding or updating tests
  • chore: Build process, auxiliary tools, libraries

Rules

  1. Subject line: imperative mood, lowercase, no period, max 50 chars
  2. Body: explain why not what (the diff shows what)
  3. Wrap body at 72 characters
  4. Reference issues when relevant: "Fixes #123"

Process

  1. Run git status and git diff --staged to understand changes
  2. If nothing staged, stage relevant files with git add
  3. Determine appropriate type and scope from the changes
  4. Write commit message following the format
  5. Do NOT add "Generated by Claude" or co-author lines

Examples

feat(pubsub): add message timestamp to publisher

Include ROS2 clock timestamp in published messages to enable
message ordering and latency measurements.

fix(subscriber): handle empty message gracefully

Previously crashed on empty string. Now logs warning and continues.