conventional-commits

Enforce Conventional Commits format for commit messages and PR titles.

2|Updated Mar 5, 2026
One-click install
npx skills add https://github.com/grimlor/universal-dev-skills --skill conventional-commits-grimlor
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: conventional-commits
Source: https://github.com/grimlor/universal-dev-skills/tree/main/skills/conventional-commits
Command: npx skills add https://github.com/grimlor/universal-dev-skills --skill conventional-commits-grimlor

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Conventional Commits prevents inconsistent or untyped commit history by enforcing a predictable commit-message structure, so downstream automation like semantic-release can determine the correct version bump.

Core Features & Use Cases

  • Consistent commit format: Enforces <type>[optional scope]: <description> with lowercase, no trailing period, and a ≤72 character subject line.
  • Clear change intent: Restricts meaningful version-bumping types to feat and fix, and supports major bumps via ! or a BREAKING CHANGE footer.
  • Safe workflow guardrails: Prohibits autonomous commits and requires showing staged diffs and requesting explicit user approval before executing git operations.
  • Release-friendly metadata: Supports footers like BREAKING CHANGE:, Refs:, and Co-authored-by: for richer changelogs and traceability.

Quick Start

Ask the agent to draft a conventional commit message for your staged changes and to request your approval before any commit is executed.

Frequently Asked Questions about conventional-commits

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

FAQPage Schema
How do I standardize commit messages for semantic release automation?

Conventional Commits standardizes commit messages by enforcing a predictable `<type>[scope]: <description>` structure. This machine-readable format allows semantic-release automation to determine the correct version bump by analyzing `feat` and `fix` types alongside breaking-change signals.

What is the correct format for a conventional commit message?

A conventional commit message requires the format `<type>[optional scope]: <description>` with lowercase text, no trailing period, and a subject line under 72 characters. Version-bumping types are restricted to `feat` and `fix`, with major bumps signaled by `!` or a `BREAKING CHANGE` footer.

How do I signal a breaking change in a pull request title using conventional commits?

Signal a breaking change in a commit message or pull request title by appending a `!` after the type or scope, or by including a `BREAKING CHANGE:` footer. This explicit signaling ensures semantic-release automation correctly triggers a major version bump.

Can I use conventional commit formatting with squash-merge workflows?

Yes, conventional commit formatting applies across interactive, automated, and squash-merge workflows. It helps draft standardized commit messages, PR titles, and changelog entries whenever you interact with git history, maintaining consistency regardless of the merge strategy.

Does this commit message formatter execute git commits automatically?

No, this commit message formatter prohibits autonomous commits. It acts as a safe workflow guardrail by requiring the agent to show staged diffs and request explicit user approval before executing any git operations, preventing unintended changes.