git-commiting

Creates git commits following the Conventional Commits specification.

Updated Mar 28, 2026
One-click install
npx skills add https://github.com/dsonyy/dotfiles --skill git-commiting-dsonyy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: git-commiting
Source: https://github.com/dsonyy/dotfiles/tree/main/skills/git-commiting
Command: npx skills add https://github.com/dsonyy/dotfiles --skill git-commiting-dsonyy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing consistent, meaningful git commit messages is hard to enforce across a project. This Skill generates commit messages that strictly follow the Conventional Commits format, keeping history readable and tooling-friendly. ## Core Features & Use Cases - Conventional Commit Formatting: Produces messages in the <type>[optional scope]: <description> format with types like feat, fix, refactor, chore, docs, test, perf, ci, and revert. - Style Enforcement: Applies rules such as lowercase imperative descriptions, no trailing period, breaking-change markers (! or BREAKING CHANGE: footer), and no Co-Authored-By trailers. - Commit Strategy Guidance: Splits work into multiple smaller commits when scope is separable and pushes after committing. - Use Case: After finishing a bug fix, ask the AI to stage and commit your changes, and receive a properly formatted message like fix(auth): handle expired refresh tokens. ## Quick Start Stage my current changes and create a conventional commit, then push it.

Frequently Asked Questions about git-commiting

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

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

Use the format `<type>[optional scope]: <description>`, such as `feat(auth): add login endpoint`. The description must be lowercase, imperative, and have no trailing period, with types like feat, fix, refactor, chore, docs, test, perf, ci, or revert.

How to mark a breaking change in a commit message?▼

Append an exclamation mark after the type or scope, like `feat!: drop v1 API`, or add a `BREAKING CHANGE:` footer in the commit body. Both forms signal a breaking change under the Conventional Commits specification.

When should I split changes into multiple commits?▼

Split changes into multiple smaller commits when the scope is easy to separate, such as independent features or fixes. If the changes are tightly coupled, one larger commit is preferred.

Should a commit message include a body?▼

Add a body only when the reason for the change is not obvious from the subject line. Leave a blank line after the subject before writing the body.

Are Co-Authored-By trailers allowed in commits?▼

No. This Skill explicitly forbids Co-Authored-By trailers in generated commit messages, along with emoji, filler words, and phrases like "this commit".