- Home
- Skills
- Wesleysmits
- Agent Skills
- Commit Message Formatter
commit-message-formatter_skill
2
GitHub Stars
1
Bundled Files
3 weeks ago
Catalog Refreshed
2 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstart where the catalogue uses aiagentskills.
npx veilstart add skill wesleysmits/agent-skills --skill commit-message-formatter- SKILL.md5.6 KB
Overview
This skill formats Git commit messages to follow the Conventional Commits specification. It analyzes staged changes, infers the appropriate type and scope, detects breaking changes, and generates a clear, release-ready commit message for user review. Use it to produce consistent, changelog-friendly commits that integrate with automation and CI tools.
How this skill works
The skill inspects staged diffs (git diff --cached) to determine the change category (feat, fix, docs, etc.), the primary affected scope, and whether the changes introduce breaking behavior. It builds a commit subject in imperative mood, wraps an optional body at 72 characters, and appends footers like BREAKING CHANGE or issue references. It presents the suggested message for approval and provides the exact git commit command to run.
When to use it
- You ask to commit staged changes or need a commit message
- You request Conventional Commits or release-ready messages
- You want consistent, changelog-friendly commit history
- You need to mark or document breaking changes
- Your team enforces commit format for automation or releases
Best practices
- Run git diff --cached to confirm staged changes before formatting
- Choose a single clear type (feat, fix, docs, etc.) that matches the primary change
- Derive scope from the main affected module or file path; omit scope for multiple areas
- Keep subject imperative, lowercase start, no trailing period, <=50 chars
- Use body to explain what and why (wrap at 72 chars); add BREAKING CHANGE or issue refs in footer
Example use cases
- Stage changes to src/auth and ask for a commit message → returns feat(auth): add ... with body and issue link
- Small typo or doc fix in README → returns docs(readme): fix installation instructions
- Bug fix changing function behavior → returns fix(api): correct token handling and includes explanation
- Major API change → returns feat(api)!: migrate to v2 response format with BREAKING CHANGE footer
- Multiple unrelated edits → suggests type without scope and prompts for manual refinement
FAQ
I will prompt you to stage files first (use git add) and show git status guidance.
How do I mark a breaking change?
Either add a ! after type/scope (feat(api)!) or include a BREAKING CHANGE: section in the footer; I will insert either based on detected removals or signature changes.