git-commit
Use this skill BEFORE running any git commit command. Triggers when about to run `git commit`. Ensures commit messages follow Conventional Commits specification.
When & Why to Use This Skill
This Claude skill streamlines the version control process by enforcing the Conventional Commits specification. It helps developers generate structured, meaningful commit messages that improve repository maintainability, facilitate automated semantic versioning, and enhance team collaboration through standardized documentation of code changes.
Use Cases
- Standardizing Project History: Automatically format commit messages using standardized types like feat, fix, and docs to maintain a clean, readable, and searchable git history.
- Automated Release Management: Enable seamless integration with CI/CD pipelines for automatic changelog generation and semantic versioning based on structured commit metadata.
- Enhanced Team Collaboration: Provide clear context and scope for every code change, making it significantly easier for team members to conduct code reviews and track feature evolution.
- Breaking Change Communication: Explicitly identify and document breaking changes using the '!' syntax or footer notes to alert collaborators and prevent downstream integration issues.
| name | git-commit |
|---|---|
| description | Use this skill BEFORE running any git commit command. Triggers when about to run `git commit`. Ensures commit messages follow Conventional Commits specification. |
Git Commit Messages
Write commit messages following the Conventional Commits specification.
Format
<type>(<scope>): <description>
[optional body]
[optional footer(s)]
Types
| Type | Purpose |
|---|---|
feat |
New feature |
fix |
Bug fix |
docs |
Documentation only |
style |
Code style (formatting, no logic change) |
refactor |
Code change that neither fixes a bug nor adds a feature |
perf |
Performance improvement |
test |
Adding or correcting tests |
build |
Build system or external dependencies |
ci |
CI configuration |
chore |
Maintenance tasks |
revert |
Reverts a previous commit |
Rules
- Use imperative mood in description ("add feature" not "added feature")
- Do not end description with a period
- Keep description under 72 characters
- Separate subject from body with a blank line
- Use body to explain what and why, not how
Breaking Changes
Add ! after type/scope or include BREAKING CHANGE: in footer:
feat(api)!: remove deprecated endpoints
BREAKING CHANGE: The /v1/users endpoint has been removed.
Scope
Optional. Use to specify area of change (e.g., api, ui, auth, db).
Attribution
Do NOT include any AI attribution, co-author tags, or generated-by footers in commit messages.