git-commits

Enforce Conventional Commits format for Git commit messages.

14|1|Updated Dec 5, 2025
One-click install
npx skills add https://github.com/jpoutrin/product-forge --skill git-commits
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-commits
Source: https://github.com/jpoutrin/product-forge/tree/main/plugins/git-workflow/skills/git-commits
Command: npx skills add https://github.com/jpoutrin/product-forge --skill git-commits

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solves?

Maintaining a clean, readable, and semantically meaningful Git commit history is essential for collaboration, code review, and release management. Inconsistent or vague commit messages hinder understanding and automation. This Skill enforces best practices for Git commits.

Core Features & Use Cases

  • Conventional Commits Format: Guidance on the standard format (<type>[optional scope]: <description>) for clear and consistent messages.
  • Commit Types: Definitions for common types like feat, fix, docs, refactor, and their semantic versioning implications.
  • Atomic Commits: Principles for ensuring each commit represents one logical, independently revertible change.
  • Commit Message Rules: Guidelines for imperative mood, line length, and handling breaking changes.
  • Claude Code Commit Footer: Specific instructions for including AI-generated attribution in commit messages.
  • Use Case: Writing a new feature commit message, fixing a bug and documenting it correctly, ensuring all commits are atomic, or generating a changelog from commit history.

Quick Start

Use the git-commits skill to generate a conventional commit message for a new feature that adds user profile editing.

Frequently Asked Questions about git-commits

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write conventional commit messages for Git?

Conventional commits follow the format `<type>[optional scope]: <description>`, where type is one of feat, fix, docs, style, refactor, perf, test, chore, ci, or build. This standardized format makes commit history readable, enables automated changelog generation, and clarifies the semantic impact of each change.

What are atomic commits and why do they matter?

Atomic commits represent one logical, independently revertible change. Each commit should be self-contained and address a single concern—whether a feature, bug fix, or documentation update. This practice improves code review clarity, enables precise git bisect debugging, and simplifies reverting specific changes without affecting unrelated work.

How do I structure commit messages to include scope and breaking changes?

Include optional scope in brackets after the type: `feat(auth): add login`. Flag breaking changes by appending `!` before the colon (`feat!: redesign API`) or by adding a `BREAKING CHANGE:` footer in the commit body. This signals to automation tools and reviewers that the change requires attention or version bump.

Can I enforce conventional commits across my Git repository?

Yes. This Skill enforces conventional commits compliance across branches, pull requests, and release workflows by validating that commit messages follow the required format with correct type prefixes, scope when needed, and line length limits—typically keeping the first line under 72 characters for readability.

What commit types should I use for different changes?

Use `feat` for new features, `fix` for bug fixes, `docs` for documentation, `style` for formatting, `refactor` for code restructuring, `perf` for performance, `test` for tests, `chore` for maintenance, `ci` for CI configuration, and `build` for build system changes. Each type signals the semantic versioning impact and purpose of the commit.

How do I generate a changelog from conventional commits?

Conventional commits enable automated changelog generation because their standardized format—with type prefixes and breaking change markers—can be parsed and organized by tools. Commits with `feat:` type become feature entries, `fix:` become bug fixes, and `!` markers highlight breaking changes for major version releases.