name	description
git-commit-message-generation	Generate Git commit messages following Conventional Commits 1.0.0 specification. Use this when committing changes, amending commits, or simply drafting commit messages.

Git commit message generation

Generate commit messages that follow strict conventions and project-specific style.

Commit message conventions

Message structure

Follow the Conventional Commits 1.0.0 specification

Format:

<type>[optional scope]: <description>

<body>

Type values

Limit commit types to exactly these values:

feat: New feature or capability
fix: Bug fix
refactor: Code change that neither fixes a bug nor adds a feature
test: Adding or modifying tests
docs: Documentation only changes
chore: Changes to build process, auxiliary tools, or maintenance tasks

Scope guidelines

Use scope to specify the area of the codebase affected, e.g., feat(auth): add OAuth2 login
Keep scope names short and lowercase
Use consistent scope names across the project by checking recent commit history
Omit scope if the change is broad or does not fit a specific area

Description rules

Use imperative, present tense, e.g., "add feature", not "added feature" or "adds feature"
Start with a lowercase letter
Never end with a period
Never begin with the type itself as a verb, e.g., fix: fix ...
Be specific and descriptive
Keep under 72 characters when possible
Use backticks to mark code elements when needed

Body guidelines

Always include a body unless the user explicitly requests title only
Wrap at approximately 72 characters per line when possible
Explain what and why, not how
Use backticks to mark code elements, e.g., variable names, function names, file paths

GitHub references

Use Fixes to close issues/PRs, never use Close, Resolved, or other alternatives
Use Updates to reference issues/PRs without closing them
Place each reference on its own line at the end of the body
References are relative to the PR target repository:
- If upstream remote exists: PR targets upstream, so #10 refers to upstream
- If no upstream remote: PR targets origin, so #10 refers to origin
Use short form #10 for issues/PRs in the PR target repository
Use full form owner/repo#10 for issues/PRs in other repositories

Forbidden elements

Never use special symbols such as arrows, em dashes, or other non-ASCII characters
Never use vague descriptions like "update code" or "fix bug"

Workflow

Gather preliminary information:
- Run git status to check for staged changes
- Run git remote -v to check remote configuration
- Get current user email for commit history filtering: git config --get user.email
Determine the scenario:
- Amend scenario: user explicitly requests amend
- Normal commit scenario: staged changes exist and user did not request amend
- If no staged changes and user did not request amend, ask if they want to amend the last commit:
  - If yes, treat as amend scenario
  - If no, inform the user that there are no staged changes and stop
Analyze changes based on scenario:
- For normal commit scenario:
  - Run git diff --staged and git diff --staged --name-status
  - Check recent commit history for style: git log --author="<email>" --format="%B---" -5
- For amend scenario:
  - Run git show HEAD to see the current commit content
  - If staged changes exist, also run git diff --staged to see additional changes
  - Check commit history before HEAD for style: git log --author="<email>" --format="%B---" -5 --skip=1
- For both scenarios, use the conversation context to understand the "why" behind changes
Generate an appropriate commit message based on both the diff and conversation context

If the user explicitly requests to make the commit (add --amend for amend scenario):

git commit -s -m "$(cat << 'EOF'
<type>[optional scope]: <description>

<body>
EOF
)"

Otherwise, present the generated message in a code block for the user to review

Language requirements

Always write commit messages in English
Use clear, professional technical language
Avoid abbreviations unless widely recognized, e.g., API, URL

Quality standards

Each commit should represent a single logical change
The message should be understandable without looking at the code
Focus on the "why" and "what" rather than the "how"
Consider the commit history as documentation for future developers

Examples

Good commit messages

feat(auth): add user authentication via OAuth2

- Add OAuth2 client configuration
- Implement token refresh logic
- Add login and logout endpoints

fix(image): resolve memory leak in `ResizeBuffer`

The buffer was not properly managed during resize operations:
- Release buffer after each resize operation
- Add cleanup in error handling paths

Fixes #123

refactor: extract email validation logic into utility function

- Move validation from `UserHandler` to `utils/validation.go`
- Move validation from `AdminHandler` to `utils/validation.go`
- Add unit tests for edge cases

This also fixes inconsistent handling of unicode characters.

test: add integration tests for payment gateway

- Add tests for successful payment flow
- Add tests for payment failure scenarios
- Add tests for refund operations

docs: update API documentation with rate limiting info

- Document rate limit headers in response

chore(deps): bump dependencies to latest stable versions

- Bump `golang.org/x/text` from 0.30.0 to 0.32.0
- Bump `github.com/stretchr/testify` from 1.8.5 to 1.9.0

Bad commit messages (never use these patterns)

fix: fix bug - redundant, repeats the type as a verb
feat: Update code - too vague, uses uppercase letter
test: added tests - wrong tense, should be "add tests"
docs: Updated README. - wrong tense, ends with period
chore: WIP - uninformative, does not describe the change

aofei/git-commit-message-generation-SKILL.md

Select an option

No results found