Skill v1.0.1
currentAutomated scan100/1006 files
version: "1.0.1" name: commit-helper description: Helps write Git commit messages following the Conventional Commits specification. Use this skill when the user asks to commit changes, write commit messages, format commits, or mentions git commits. allowed-tools: Read, Write, Edit, Bash, Grep metadata: hooks: after_complete:
- trigger: session-logger
mode: auto reason: "Log commit activity"
Commit Message Helper
A skill for creating properly formatted Git commit messages following the Conventional Commits specification.
When This Skill Activates
This skill activates when you:
- Ask to commit changes
- Mention commit messages
- Request git commit formatting
- Say "commit" or "git commit"
Commit Message Format
<type>(<scope>): <subject><body><footer>
Types
| Type | Description | |
|---|---|---|
feat | A new feature | |
fix | A bug fix | |
docs | Documentation only changes | |
style | Changes that do not affect the meaning of the code (formatting, 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 | |
chore | Changes to the build process or auxiliary tools | |
ci | Changes to CI configuration files and scripts | |
build | Changes that affect the build system or external dependencies |
Scope
The scope should indicate the area of the codebase affected:
- For frontend:
components,hooks,store,styles,utils - For backend:
api,models,services,database,auth - For devops:
ci,deploy,docker - Project-specific scopes are also acceptable
Guidelines
Subject Line
- Use imperative mood ("add feature" not "added feature" or "adds feature")
- No period at the end
- Maximum 50 characters
- Be specific and concise
Body
- Separate subject from body with a blank line
- Use the body to explain what and why, not how
- Wrap at 72 characters per line
- Mention any breaking changes
Footer
- Reference issues:
Closes #123,Fixes #456,Refs #789 - Multiple issues:
Closes #123, #456, #789 - Breaking changes: Start with
BREAKING CHANGE:followed by description
Examples
Good Examples
feat(auth): add OAuth2 login supportImplement OAuth2 authentication flow to allow users to log inwith their Google or GitHub accounts.This change adds:- New OAuth2 middleware for handling callbacks- Updated login UI with social login buttons- User profile synchronizationCloses #123
fix(api): resolve race condition in user creationThe concurrent user creation requests could result in duplicateemail entries. Added unique constraint and proper error handling.Fixes #456
refactor(user): simplify profile update logicExtracted common validation logic into a reusable functionto reduce code duplication across profile update endpoints.
docs: update API documentation with new endpointsAdded documentation for the v2 user management endpointsincluding request/response examples and error codes.
Bad Examples
updated stuff # Too vague, no type/scopefixed bug # No context about which bugfeat: added feature # Redundant ("feat" means new feature)Feat(User): Add Login # Incorrect capitalizationfeat: A really really really long subject line that exceeds the recommended limit # Too long
Breaking Changes
When introducing breaking changes, add BREAKING CHANGE: to the footer:
feat(api): migrate to REST v2The API endpoints have been restructured for better consistency.Old endpoints are deprecated and will be removed in v3.0.BREAKING CHANGE: `/api/v1/users` is now `/api/v2/users`.All consumers must update their integration by 2025-03-01.
Workflow
When writing a commit message:
- Review changes - Run
git diffto understand what changed - Identify type - Determine the type of change
- Identify scope - Determine which area is affected
- Write subject - Create a clear, concise subject line
- Write body - Explain what and why (if needed)
- Add footer - Reference issues or note breaking changes
Validation
Use the validation script to check commit message format:
python scripts/validate_commit.py "your commit message"
Reference Documents
- See
references/conventional-commits.mdfor full specification - See
references/examples.mdfor more examples - See
references/scopes.mdfor recommended scope naming