git-commit-formatter

Format staged git changes into type-based commit messages.

7|1|Updated Jul 27, 2021
One-click install
npx skills add https://github.com/podcodar/webapp --skill git-commit-formatter-podcodar
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-commit-formatter
Source: https://github.com/podcodar/webapp/tree/main/.agents/skills/git-commit-formatter
Command: npx skills add https://github.com/podcodar/webapp --skill git-commit-formatter-podcodar

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It solves the problem of inconsistent, unclear git commit messages by turning staged changes into a short, structured, type-driven message that fits a shared team convention.

Core Features & Use Cases

  • Type-based commit formatting: Generates commit messages using simplified types (fea, fix, ref, ai, test, oth) to keep AI output concise and consistent.
  • Scope-aware descriptions: Encourages adding a scope when it clarifies which component changed, improving readability in project history.
  • Breaking-change footers: Supports appending a BREAKING CHANGE footer when the user indicates a breaking change.

Quick Start

Ask the AI to produce a git commit message for your staged changes using the format type(optional scope): description.

Frequently Asked Questions about git-commit-formatter

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

FAQPage Schema
How do I format git commit messages for staged changes?

Formatting git commit messages involves applying a type-based convention to staged changes. The formatter selects a dominant type from a table (fea, fix, ref, ai, test, oth), enforces lowercase, and writes an imperative-mood description under 72 characters.

What is the conventional format for writing git commit messages?

The conventional format for git commit messages is a structured syntax: type(optional scope): description. It uses simplified types like fea, fix, ref, ai, test, or oth to keep project history concise and consistent across development workflows.

How do I indicate a breaking change in a conventional commit message?

You indicate a breaking change in a conventional commit message by appending a BREAKING CHANGE footer. The formatter adds this footer when you specify that the staged development work introduces backward-incompatible modifications.

Does the commit formatter support adding a scope to the commit type?

Yes, the commit formatter supports adding a scope to the commit type. It encourages including a scope when it clarifies which component changed, generating scope-aware descriptions that improve readability in project history.

What is the character limit for the first line of a git commit message?

The character limit for the first line of a git commit message is 72 characters. The formatter enforces this constraint while ensuring the description uses lowercase formatting and imperative-mood phrasing for structured consistency.

When do I need to use a type-based convention for git commits?

You need to use a type-based convention for git commits when you want to solve the problem of inconsistent, unclear project history. It turns staged development work into short, structured messages that fit a shared team convention.