How do I install the Commit Formatter skill?

Run npx skillmds add majiayu000/commit-formatter in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Commit Formatter safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: makes network calls, reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Commit Formatter?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Commit Formatter free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Commit Formatter?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Commit Formatter by majiayu000 — Agent Skill

Name: Commit Formatter
Rating: 4.2 (5 reviews)
Author: majiayu000

File contents

Commit Formatter Skill

When to Use

This skill MUST be used when:

User asks to create a git commit message
User requests help with commit message format
User mentions "conventional commits" or commit standards
User asks how to format commits for their repository

What This Skill Does

Guides users in creating well-formatted git commit messages following the Conventional Commits specification (https://www.conventionalcommits.org/):

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Types

feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Changes that don't affect code meaning (formatting, whitespace)
refactor: Code change that neither fixes a bug nor adds a feature
perf: Performance improvements
test: Adding or correcting tests
chore: Changes to build process or auxiliary tools
ci: CI configuration changes
build: Changes to build system or dependencies

Instructions

When helping users format commits:

Analyze the changes: Ask about or review what was changed
Determine the type: Select the most appropriate commit type
Identify scope (optional): If changes are isolated to a component/module
Write description: Short (max 50 chars), imperative mood ("add" not "added")
Add body (if needed): Explain what and why, not how (wrap at 72 chars)
Add footers (if needed): Breaking changes, issue references

Examples

Simple Feature

feat: add user authentication to API

Feature with Scope

feat(auth): implement JWT token refresh mechanism

Bug Fix with Body

fix: prevent race condition in user signup

The signup process was not properly locking user records,
causing duplicate accounts when multiple requests arrived
simultaneously. Added transaction locking to prevent this.

Breaking Change

feat!: change API response format to match REST standards

BREAKING CHANGE: API responses now return data in 'data' field
instead of root level. Update all API clients accordingly.

With Issue Reference

fix: correct validation error in email field

Fixes #123

Best Practices

Keep the first line under 50 characters
Separate subject from body with blank line
Use imperative mood ("change" not "changed" or "changes")
Explain what and why in the body, not how
Reference issues and PRs in footer
Use ! or BREAKING CHANGE: for breaking changes
One logical change per commit

Platform Compatibility

This skill works on:

Claude Code (recommended - can analyze git diff)
Claude.ai (provide change description)
Claude API (integrate in your git workflow)

---name: commit-formatterdescription: Use this skill when the user needs help formatting git commit messages according to Conventional Commits specification. Provides guidance on commit types, scope, and message structure.--- # Commit Formatter Skill ## When to Use This skill MUST be used when: - User asks to create a git commit message - User requests help with commit message format - User mentions "conventional commits" or commit standards - User asks how to format commits for their repository ## What This Skill Does Guides users in creating well-formatted git commit messages following the Conventional Commits specification (https://www.conventionalcommits.org/): ``` <type>[optional scope]: <description> [optional body] [optional footer(s)] ``` ## Commit Types - **feat**: A new feature - **fix**: A bug fix - **docs**: Documentation only changes - **style**: Changes that don't affect code meaning (formatting, whitespace) - **refactor**: Code change that neither fixes a bug nor adds a feature - **perf**: Performance improvements - **test**: Adding or correcting tests - **chore**: Changes to build process or auxiliary tools - **ci**: CI configuration changes - **build**: Changes to build system or dependencies ## Instructions When helping users format commits: 1. **Analyze the changes**: Ask about or review what was changed 2. **Determine the type**: Select the most appropriate commit type 3. **Identify scope** (optional): If changes are isolated to a component/module 4. **Write description**: Short (max 50 chars), imperative mood ("add" not "added") 5. **Add body** (if needed): Explain what and why, not how (wrap at 72 chars) 6. **Add footers** (if needed): Breaking changes, issue references ## Examples ### Simple Feature ``` feat: add user authentication to API ``` ### Feature with Scope ``` feat(auth): implement JWT token refresh mechanism ``` ### Bug Fix with Body ``` fix: prevent race condition in user signup The signup process was not properly locking user records, causing duplicate accounts when multiple requests arrived simultaneously. Added transaction locking to prevent this. ``` ### Breaking Change ``` feat!: change API response format to match REST standards BREAKING CHANGE: API responses now return data in 'data' field instead of root level. Update all API clients accordingly. ``` ### With Issue Reference ``` fix: correct validation error in email field Fixes #123 ``` ## Best Practices - Keep the first line under 50 characters - Separate subject from body with blank line - Use imperative mood ("change" not "changed" or "changes") - Explain what and why in the body, not how - Reference issues and PRs in footer - Use `!` or `BREAKING CHANGE:` for breaking changes - One logical change per commit ## Platform Compatibility This skill works on: - Claude Code (recommended - can analyze git diff) - Claude.ai (provide change description) - Claude API (integrate in your git workflow)

Frequently asked questions