generating-commit-messages

wincent's avatarfrom wincent

Generates clear commit messages from Git diffs. Use when writing commit messages or reviewing staged changes.

⭐1.2kstars🔀105forks📁View on GitHub🕐Updated Jan 8, 2026
[Developer Tools]

When & Why to Use This Skill

This Claude skill automates the creation of professional and standardized Git commit messages by analyzing code diffs. It streamlines the version control process by ensuring all commits follow the Conventional Commits specification, which improves project traceability, simplifies code reviews, and facilitates automated changelog generation.

Use Cases

  • Standardizing repository history: Automatically generating commit messages that follow the 'type: description' format (e.g., feat, fix, docs) to maintain a clean and searchable Git log.
  • Enhancing code review efficiency: Providing reviewers with clear, concise summaries of changes and the reasoning behind them, rather than just a list of modified lines.
  • Automating documentation workflows: Using structured commit messages to enable tools that automatically generate release notes and version updates based on the commit history.
  • Improving developer productivity: Reducing the cognitive load on developers by drafting detailed descriptions of complex changes, allowing them to focus on coding rather than documentation.
namegenerating-commit-messages
descriptionGenerates clear commit messages from Git diffs. Use when writing commit messages or reviewing staged changes.

Generating Commit Messages

Instructions

  1. Run command git diff to see changes that will be committed (or command git diff --staged if they have already been staged).
  2. Suggest a commit message with:
  • A subject of 72 characters or less in Conventional Commits format (eg. "docs: add migration notes" or "fix: avoid double-render in list component").
  • A detailed description, wrapped to 72 characters, using basic Markdown syntax.

Best practices

  • Subjects should start with a type (eg. "docs", "fix", "feat", "chore" etc) following by a statement beginning with a verb (eg. "add", "remove", "rename" etc).
  • Explain what and why, not how.
  • Note alternatives which were considered but not implemented.
  • Include references to previous commits or other artifacts (documentation, PRs) that are relevant.