git-commit-formatter

Formats git commit messages according to the Conventional Commits specification.

1|Updated Mar 19, 2026
One-click install
npx skills add https://github.com/tottenjordan/me-skittles --skill git-commit-formatter-tottenjordan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: git-commit-formatter
Source: https://github.com/tottenjordan/me-skittles/tree/main/gemini/git-commit-formatter
Command: npx skills add https://github.com/tottenjordan/me-skittles --skill git-commit-formatter-tottenjordan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Inconsistent or vague commit messages make project history hard to read, break changelog automation, and slow down code review. This Skill ensures every commit message follows the Conventional Commits specification with the correct type, scope, and imperative description. ## Core Features & Use Cases - Conventional Commits enforcement: Produces messages in the <type>[optional scope]: <description> format using allowed types such as feat, fix, docs, refactor, perf, test, style, and chore. - Change analysis: Inspects the staged changes to determine the primary commit type and an appropriate scope. - Breaking change handling: Adds a BREAKING CHANGE: footer when the changes introduce breaking modifications. - Use Case: After staging a new login feature, ask for a commit message and receive feat(auth): implement login with google instead of a vague note like "update code". ## Quick Start Ask the agent to write a commit message for your staged changes following the Conventional Commits format.

Frequently Asked Questions about git-commit-formatter

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

FAQPage Schema
How do I write a Conventional Commits message for my changes?▼

Use the format `<type>[optional scope]: <description>`, choosing a type like feat, fix, docs, refactor, perf, test, style, or chore. Write the description in imperative mood, such as `feat(auth): implement login with google`.

What commit types are allowed in Conventional Commits?▼

The allowed types are feat for new features, fix for bug fixes, docs for documentation, style for formatting, refactor for code restructuring, perf for performance, test for tests, and chore for build or tooling changes.

How do I mark a breaking change in a commit message?▼

Add a footer starting with `BREAKING CHANGE:` after the description. This signals to consumers and tooling that the commit introduces backward-incompatible modifications.

When should I include a scope in a commit message?▼

Include a scope in parentheses after the type when the change targets a specific component, module, or file, such as `fix(parser): handle empty input`. Omit it when the change spans the whole project.

Why should commit descriptions use imperative mood?▼

Imperative mood ("add feature" not "added feature") keeps messages consistent with git's own conventions and generated messages like merge commits. It reads as a command describing what applying the commit will do.