formatting-commit-messages
4
总安装量
2
周安装量
#53546
全站排名
安装命令
npx skills add https://github.com/wesleysmits/agent-skills --skill formatting-commit-messages
Agent 安装分布
opencode
2
gemini-cli
2
claude-code
2
cursor
2
mcpjam
1
Skill 文档
Commit Message Formatter (Conventional Commits)
When to use this skill
- User asks to commit staged changes
- User wants help writing a commit message
- User mentions “conventional commits” or commit formatting
- User asks for release-ready or changelog-friendly commits
- User wants to ensure commits follow team standards
Workflow
- Check for staged changes using
git diff --cached - Analyze the nature of the changes (new feature, bug fix, refactor, etc.)
- Determine appropriate type prefix
- Identify scope from affected files/modules
- Check for breaking changes
- Generate formatted commit message
- Present message for user approval
- Execute commit if approved
Conventional Commits Format
<type>[optional scope][!]: <description>
[optional body]
[optional footer(s)]
Type Prefixes
| Type | When to Use |
|---|---|
feat |
New feature for the user |
fix |
Bug fix for the user |
docs |
Documentation only changes |
style |
Formatting, missing semicolons (no code change) |
refactor |
Code change that neither fixes nor adds feature |
perf |
Performance improvement |
test |
Adding or correcting tests |
build |
Changes to build system or dependencies |
ci |
CI configuration changes |
chore |
Other changes that don’t modify src or tests |
revert |
Reverts a previous commit |
Breaking Changes
- Add
!after type/scope:feat(api)!: remove deprecated endpoints - OR add
BREAKING CHANGE:footer in the body
Instructions
Step 1: Analyze Staged Changes
Run the following to get staged diffs:
git diff --cached --stat
git diff --cached
Step 2: Determine Commit Type
Analyze the changes to determine the appropriate type:
- New files in
src/with new functionality âfeat - Modified files fixing incorrect behavior â
fix - Changes only to
*.md,*.txt, or docs folder âdocs - Only whitespace/formatting changes â
style - Code restructuring without behavior change â
refactor - Performance optimizations â
perf - New or updated test files â
test - Changes to
package.json,webpack.config.*,tsconfig.*âbuild - Changes to
.github/workflows/, CI configs âci - Dependency updates, config tweaks â
chore
Step 3: Identify Scope
Derive scope from the primary affected area:
src/components/Button.tsxâ scope:buttonsrc/api/users.tsâ scope:apioruserslib/utils/â scope:utils- Multiple unrelated areas â omit scope
Step 4: Detect Breaking Changes
Look for indicators of breaking changes:
- Removed public functions or exports
- Changed function signatures (parameters, return types)
- Renamed public APIs
- Changed default behavior
- Removed configuration options
Step 5: Compose the Message
Subject line rules:
- Use imperative mood: “add” not “added” or “adds”
- No capital letter at start
- No period at the end
- Max 50 characters (hard limit: 72)
Body (if needed):
- Wrap at 72 characters
- Explain what and why, not how
- Separate from subject with blank line
Footer (if needed):
BREAKING CHANGE: <description>Fixes #123orCloses #456Reviewed-by: Name <email>
Step 6: Present and Commit
Present the formatted message to the user:
**Suggested commit message:**
feat(auth): add OAuth2 login support
Implement OAuth2 authentication flow with Google and GitHub providers.
Users can now sign in using their existing accounts.
Closes #142
If approved, execute:
git commit -m "<subject>" -m "<body>" -m "<footer>"
Or for simple commits:
git commit -m "<type>(<scope>): <description>"
Examples
Simple Feature
feat(cart): add quantity selector to cart items
Bug Fix with Issue Reference
fix(auth): prevent token refresh race condition
Multiple simultaneous requests could trigger parallel refresh attempts.
Added mutex lock to ensure single refresh execution.
Fixes #287
Breaking Change
feat(api)!: migrate to v2 response format
BREAKING CHANGE: API responses now use camelCase keys instead of snake_case.
All clients must update their parsing logic.
Documentation Update
docs(readme): add installation instructions for Windows
Refactor
refactor(utils): extract date formatting into separate module
Validation
Before committing, verify:
- Type accurately reflects the change
- Scope is specific but not overly narrow
- Subject is in imperative mood
- Subject is under 50 characters
- Breaking changes are properly marked
- Related issues are referenced
Error Handling
- No staged changes: Run
git statusto confirm. Prompt user to stage files first. - Commit fails: Check
git statusfor conflicts or hooks blocking commit. - Unsure about a command: Run
git commit --helpfor options.