| name | conventional-commit |
| description | Create Conventional Commit messages from staged git changes. Activate when the user asks to create a commit, write a commit message, commit staged changes, generate a semantic commit, generate a conventional commit, or summarize staged changes for a commit. |
| allowed-tools | Bash(git diff:*) |
Git Commit Message Skill
When asked to create a Git commit message, follow these rules.
1. Analyze only staged changes
- Use
git diff --cached to inspect the changes.
- Do not consider unstaged or untracked files.
- If there are no staged changes, report that no commit message can be generated.
2. Gather context
Use the following command:
git diff --cached
Inspect only the staged changes.
3. Use Conventional Commits
Format:
<type>(<scope>): <summary>
Examples:
feat(logs): change logs format
fix(auth): handle empty response
refactor(api): simplify payload mapping
4. Allowed commit types
Choose the most appropriate type:
| Type | Description |
|---|
| feat | New functionality |
| fix | Bug fix |
| refactor | Internal code change without behavior change |
| perf | Performance improvement |
| test | Tests added or updated |
| docs | Documentation changes |
| style | Formatting only, no logic changes |
| build | Build system or dependency changes |
| ci | CI/CD changes |
| chore | Maintenance work |
Prefer:
- feat only when user-visible behavior or functionality is added.
- fix only when correcting incorrect behavior.
- refactor when behavior remains unchanged.
- chore for configuration, dependency, or maintenance changes.
5. Determine the scope
Infer the scope from the functionality affected by the staged changes.
Possible examples:
- logs
- auth
- api
- config
- validation
- notifications
- payments
- database
- monitoring
- metrics
Rules:
- Use a short, meaningful scope that represents the area of the application being modified.
- Infer the scope from the staged changes.
- Do not use file names unless they clearly represent a functional area.
- Omit the scope if no clear scope can be identified.
Examples:
feat(logs): change logs format
fix(validation): handle missing required field
refactor(api): simplify payload mapping
chore(config): update environment variables
6. Generate the summary
The summary must:
- Be written in English.
- Use lowercase except for acronyms or proper names.
- Be concise and descriptive.
- Use present tense.
- Not end with a period.
- Prefer a single line.
- Describe the primary purpose of the staged changes.
Good examples:
change logs format
add retry mechanism for api calls
handle empty response from provider
simplify payload mapping
update validation rules
Bad examples:
changes
fix stuff
update code
various improvements
7. Commit body
Prefer a single-line commit message.
Only add a body when:
- The change is complex.
- Multiple related modifications were made.
- Additional context is necessary.
Example:
feat(api): add retry mechanism for provider calls
- add exponential backoff strategy
- retry transient network failures
- improve logging for failed attempts
8. Output format
Return only the commit message.
Do not include:
- Explanations
- Analysis
- Markdown formatting
- Code fences
- Alternative suggestions
Output exactly the final commit message.
IMPORTANT
- NEVER add this text to the commit message: Co-authored-by: Copilot...
