home / skills / aig787 / agpm / commit-message-generator

commit-message-generator skill

safe

/examples/deps/skills/commit-message-generator

This skill generates conventional commit messages by analyzing git diff and applying type, scope, and formatting guidelines for clear history.

npx playbooks add skill aig787/agpm --skill commit-message-generator

Review the files below or copy the command above to add this skill to your agents.

Files (4)

SKILL.md

2.8 KB

---
name: commit-message-generator
description: Generate conventional commit messages based on git diff analysis. Use when you need to create well-structured commit messages following conventional commit format.
---

# Commit Message Generator

## Instructions

When generating commit messages, follow these guidelines:

### 1. Analyze the Git Diff
- Examine all staged and unstaged changes
- Identify the main purpose of the changes
- Look for breaking changes, new features, or bug fixes

### 2. Choose the Appropriate Type
Use one of these conventional commit types:
- `feat`: New feature or enhancement
- `fix`: Bug fix or regression
- `docs`: Documentation changes only
- `style`: Code style changes (formatting, missing semicolons, etc.)
- `refactor`: Code refactoring without functional changes
- `test`: Adding or updating tests
- `chore`: Maintenance tasks, dependency updates, etc.
- `perf`: Performance improvements
- `ci`: CI/CD configuration changes
- `build`: Build system or dependency changes

### 3. Format the Commit Message
```
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
```

#### Rules:
- Keep the description under 72 characters
- Use imperative mood ("add" not "added" or "adds")
- Include scope if the change affects a specific module/component
- Add "BREAKING CHANGE:" footer for breaking API changes
- Reference issues with "Closes #123" or "Resolves #456"

### 4. Examples

#### Simple Feature
```
feat(cli): add --verbose flag for detailed output

Adds a new verbose flag that displays detailed progress information
during installation and update operations.
```

#### Bug Fix
```
fix(cache): resolve worktree cleanup issue on Windows

The worktree cleanup logic was failing on Windows due to path
separator mismatches. This fix ensures proper path normalization.

Closes #123
```

#### Breaking Change
```
feat(api): change dependency resolution return type

The resolve_dependencies function now returns a Result<Dependencies>
instead of (Dependencies, Warnings) for better error handling.

BREAKING CHANGE: This changes the function signature and requires
callers to handle the Result type.
```

### 5. Special Cases
- For multiple unrelated changes, create multiple commits
- For WIP (work in progress), use "WIP:" prefix
- For revert commits, use "revert: <original commit message>"
- For merge commits, use "Merge branch 'feature-branch'"

## Usage

1. Stage your changes with `git add`
2. Run this skill to analyze the changes
3. Review and edit the generated commit message if needed
4. Commit with `git commit -m "<message>"`

## Tips

- Focus on what the change does, not how it was implemented
- Be specific but concise in the description
- Consider future readers when writing the message
- Link to related documentation or issues when relevant

Overview

This skill generates conventional commit messages by analyzing your git diff to produce clear, structured commit summaries. It produces concise, imperative descriptions, optional scoped context, and formatted bodies/footers following Conventional Commits. Use it to speed up commits and keep commit history consistent and machine-readable.

How this skill works

The tool inspects staged and unstaged changes to identify the primary purpose: new feature, bug fix, refactor, docs, tests, etc. It classifies the change into a conventional commit type, suggests an optional scope when a specific module is affected, and composes a short description plus an optional explanatory body and footers (e.g., BREAKING CHANGE or issue references). The output adheres to length and mood rules and highlights suggested edits before you commit.

When to use it

When you want consistent, machine-parsable commit messages
Before committing staged or unstaged changes to enforce Conventional Commits
When creating commits that should reference issues or include breaking-change notices
When preparing a changelog or automating release notes
When contributing to projects that require structured commit history

Best practices

Stage only related changes and run the generator per logical change
Keep description under 72 characters and use imperative mood
Include a scope for module-specific changes to improve clarity
Add a body for rationale, migration notes, or non-obvious behavior changes
Use BREAKING CHANGE footer when an API or behavior change requires manual action

Example use cases

Add a new CLI flag: generates feat(cli): add --verbose flag and body explaining effects
Fix platform-specific bug: generates fix(cache): resolve worktree cleanup issue on Windows with issue reference
Introduce performance improvement: generates perf(db): reduce query allocations and describes benchmark results
Refactor without behavior change: generates refactor(auth): simplify token validation logic
Document changes only: generates docs(readme): update installation instructions and link to updated docs

FAQ

Will it commit for me automatically?

No. It generates a suggested commit message for you to review and edit; you still run git commit to apply it.

How does it detect breaking changes?

It looks for code or API changes that alter function signatures, public behavior, or explicit markers in diffs and will prompt to add a BREAKING CHANGE footer when detected.