write-commit-message
Use when creating git commits. Defines conventional commit format and message structure guidelines.
When & Why to Use This Skill
This Claude skill standardizes the Git workflow by enforcing the Conventional Commits specification. It provides a structured framework for writing clear, consistent, and machine-readable commit messages, which facilitates better team collaboration, automated changelog generation, and streamlined project maintenance.
Use Cases
- Standardizing Team Contributions: Ensures all team members follow the same commit format (feat, fix, docs, etc.), making the project history easy to navigate and audit.
- Automated Release Management: Enables the use of tools like semantic-release to automatically determine version bumps and generate changelogs based on structured commit types.
- Improving Code Review Efficiency: Helps reviewers quickly understand the intent and scope of changes through standardized prefixes and clear description guidelines.
- Integration with CI/CD Pipelines: Facilitates automated workflows that trigger specific actions based on the commit type, such as running specific test suites for 'fix' or 'feat' commits.
- Maintaining Clean Project Metadata: Prevents AI-generated noise and ensures commit messages remain focused on technical changes rather than attribution.
| name | write-commit-message |
|---|---|
| description | Use when creating git commits. Defines conventional commit format and message structure guidelines. |
Commit Message Guidelines
Guidelines for writing clear, consistent git commit messages.
Conventional Commits Format
Use the conventional commits style:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Full Format with All Options
<type>[optional scope]!: <description>
[optional body]
[optional footer: value]
[optional footer: value]
Commit Types
- feat: New feature
- fix: Bug fix
- test: Adding or updating tests
- docs: Documentation changes
- refactor: Code refactoring (no functional changes)
- style: Code style changes (formatting, whitespace)
- chore: Maintenance tasks, dependencies
- perf: Performance improvements
- ci: CI/CD configuration changes
- build: Build system changes
Scope (Optional)
Add scope in parentheses to provide additional context:
Breaking Changes
Indicate breaking changes with ! after type/scope:
Description Guidelines
- Use imperative mood ("add feature" not "added feature")
- Start with lowercase
- No period at the end
- Keep under 72 characters
- Be specific and descriptive
Multi-line Commits
For complex changes, use a body to provide context:
Footers
Footers provide metadata about the commit.
Breaking Changes
Document breaking changes in footer:
Commit Message Customization
IMPORTANT: Do NOT include AI attribution footers like:
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Keep commit messages clean and focused on the changes themselves.
Before Committing
- Check for remote updates:
git fetch - Review your changes:
git statusandgit diff - Stage relevant files:
git add <files> - Write clear commit message
Commit Frequency
- Commit logical units of work
- Don't commit half-finished features
- Ensure tests pass before committing
- One commit per requirement or bug fix (when practical)
Integration with STDD Workflow
When following the spec-test-driven development workflow:
- After completing a requirement (spec + test + implementation)
- Ensure all tests pass
- Run any precommit hooks
- Commit with descriptive message
- Reference requirement ID in commit body if helpful