How do I install the Git Commit Conventional skill?

Run npx skillmds@latest add majiayu000/git-commit-conventional 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.

What does the Git Commit Conventional skill do?

Generate conventional commit messages with strict formatting rules It is listed under Coding & Dev Tools on SkillMD.

Is Git Commit Conventional safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Git Commit Conventional?

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 Git Commit Conventional free to use?

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

Who published Git Commit Conventional?

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

Git Commit Conventional by majiayu000

Name: Git Commit Conventional
Rating: 4.2 (5 reviews)
Author: majiayu000

File contents

Git Commit Conventional Skill

Overview

Generate conventional commit messages for staged changes.

Usage

/git-commit-conventional

Identity

Role: Commit Message Author Objective: Generate a commit message for the currently staged changes that strictly follows the Conventional Commits specification.

Rules & Standards

Format

<type>(<scope>): <subject>

[optional body]

[optional footer]

Allowed Types

feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing tests or correcting existing tests
build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
chore: Other changes that don't modify src or test files

Scope Determination

Dynamic: The scope should be the directory name or component name affected (e.g., auth, ui, api).
Specific: Avoid broad scopes like global or app unless truly global.

Subject Rules

Use strict imperative mood ("add" not "added", "fix" not "fixed").
Max 50 characters.
No period at the end.
Lowercase first letter.

Workflow

Read Staged Diff: git diff --cached.
Analyze Intent: What does this change achieve?
Draft Message: Apply the formatting rules.
Review: Check against constraints (max length, imperative mood).

Examples

Good: feat(auth): implement jwt signing
Bad: Fixed login bug. (Not conventional, past tense, period)
Bad: feat(User): Added user. (Capitalized scope/subject, past tense)

Error Handling

If the diff includes multiple unrelated changes, suggest splitting the commit (ref: git-committer-atomic).
If no files are staged, abort and ask user to stage files.

Outputs

Conventional commit message aligned to staged changes.

Related Skills

/git-committer-atomic - Plan atomic commits

---name: git-commit-conventionaldescription: Generate conventional commit messages with strict formatting rules--- # Git Commit Conventional Skill ## Overview Generate conventional commit messages for staged changes. ## Usage ``` /git-commit-conventional ``` ## Identity **Role**: Commit Message Author **Objective**: Generate a commit message for the *currently staged* changes that strictly follows the Conventional Commits specification. ## Rules & Standards ### Format ```text <type>(<scope>): <subject> [optional body] [optional footer] ``` ### Allowed Types - `feat`: A new feature - `fix`: A bug fix - `docs`: Documentation only changes - `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) - `refactor`: A code change that neither fixes a bug nor adds a feature - `perf`: A code change that improves performance - `test`: Adding missing tests or correcting existing tests - `build`: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) - `ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) - `chore`: Other changes that don't modify src or test files ### Scope Determination - **Dynamic**: The scope should be the directory name or component name affected (e.g., `auth`, `ui`, `api`). - **Specific**: Avoid broad scopes like `global` or `app` unless truly global. ### Subject Rules - Use strict **imperative mood** ("add" not "added", "fix" not "fixed"). - Max 50 characters. - No period at the end. - Lowercase first letter. ## Workflow 1. **Read Staged Diff**: `git diff --cached`. 2. **Analyze Intent**: What does this change achieve? 3. **Draft Message**: Apply the formatting rules. 4. **Review**: Check against constraints (max length, imperative mood). ## Examples - **Good**: `feat(auth): implement jwt signing` - **Bad**: `Fixed login bug.` (Not conventional, past tense, period) - **Bad**: `feat(User): Added user.` (Capitalized scope/subject, past tense) ## Error Handling - If the diff includes multiple unrelated changes, suggest splitting the commit (ref: `git-committer-atomic`). - If no files are staged, abort and ask user to stage files. ## Outputs - Conventional commit message aligned to staged changes. ## Related Skills - `/git-committer-atomic` - Plan atomic commits

Frequently asked questions

Git Commit Conventional