conventional-git

Generate Conventional Commits messages and branch names with breaking-change syntax.

1|Updated May 28, 2026
One-click install
npx skills add https://github.com/SilvrDuck/skills --skill conventional-git-silvrduck
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: conventional-git
Source: https://github.com/SilvrDuck/skills/tree/main/skills/conventional-git
Command: npx skills add https://github.com/SilvrDuck/skills --skill conventional-git-silvrduck

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Conventional Git prevents inconsistent commit messages and branch naming by giving you a compact, practical cheat sheet for Conventional Commits and Conventional Branch conventions.

Core Features & Use Cases

  • Commit message formatting: Produces clean subjects like <type>(<optional-scope>): <description> with correct imperative mood and breaking-change signaling (! and/or BREAKING CHANGE).
  • Branch naming guidance: Helps choose the right branch type and generate readable, kebab-case branch names like feature/short-description or spike/... for throwaway, no-merge research.
  • Fast decisioning: Guides you to pick the most fitting type/branch type based on what you’re about to do (feature, fix, hotfix, release prep, chore, or spike).

Quick Start

Use conventional-git when you’re about to run git commit or create a new branch and ask what exact <type>(<scope>): <description> and branch format best match your change.

Frequently Asked Questions about conventional-git

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

FAQPage Schema
How do I format a git commit message for breaking changes?

Format breaking changes in git commit messages by appending `!` after the type/scope, like `feat(api)!: drop v1 endpoints`, or by adding a `BREAKING CHANGE:` footer detailing the migration impact. This signals major version bumps to automated tooling.

How do I name a git branch for a research spike?

Name a git branch for a research spike using the `spike/` prefix followed by a kebab-case description, such as `spike/test-new-framework`. This distinguishes throwaway, no-merge research branches from feature or fix branches.

What is the correct syntax for conventional commits?

Conventional commits syntax follows `<type>(<optional-scope>): <description>`, using types like `feat`, `fix`, or `chore`, with the description written in imperative mood to standardize commit history and generate changelogs.

How do I choose the right git branch type for my pull request?

Choose the right git branch type by matching your task: `feature/` for new functionality, `fix/` for bug fixes, `hotfix/` for urgent production issues, `release/` for release prep, and `chore/` for maintenance tasks.

When do I need to use a BREAKING CHANGE footer instead of the ! syntax?

Use a `BREAKING CHANGE:` footer when you need to provide detailed migration notes alongside the commit, and use the `!` syntax after the type for simple signaling; both correctly indicate breaking changes per the Conventional Commits 1.0.0 specification.