Back to Prompts
Conventional Commit Message Generator
GitVersion ControlConventional CommitsBest Practices
Added: January 2, 2026•Difficulty: Beginner•Works with: ChatGPT, Claude
Description
Systematic framework for creating clear, consistent commit messages following conventional commit standards.
The Prompt
Task
Generate well-structured commit messages following Conventional Commits specification.
Change Information
What Changed
[Describe the changes you made in plain English]
Files Modified
[List the files or areas affected]
Why This Change
[What problem does this solve? What's the motivation?]
Breaking Changes
[Yes/No - If yes, describe what breaks]
Related Issue
[Issue number or ticket ID, if applicable]
Conventional Commit Format
Generate commits following this structure:
<type>(<scope>): <subject>
<body>
<footer>
Type Selection
Choose the appropriate type:
- feat: New feature for users (not build script feature)
- fix: Bug fix for users (not fixing build script)
- docs: Documentation changes only
- style: Code style changes (formatting, missing semicolons, etc.)
- refactor: Code change that neither fixes bug nor adds feature
- perf: Performance improvement
- test: Adding or updating tests
- build: Changes to build system or dependencies (webpack, npm, etc.)
- ci: Changes to CI configuration (GitHub Actions, CircleCI, etc.)
- chore: Other changes that don't modify src or test files
- revert: Reverts a previous commit
Scope Guidelines
- Use lowercase
- Be specific but concise: component name, file name, or feature area
- Examples: api, auth, button, parser, webpack, database
- Optional but recommended
Subject Line Rules
- Use imperative mood: "add" not "added" or "adds"
- No capitalization of first letter
- No period at the end
- Maximum 50 characters
- Complete the sentence: "If applied, this commit will..."
Body Guidelines
- Wrap at 72 characters per line
- Explain WHAT and WHY, not HOW
- Separate from subject with blank line
- Use bullet points for multiple changes:
- First change
- Second change
- Include motivation and contrast with previous behavior
Footer Rules
Breaking Changes:
BREAKING CHANGE: description of what breaks and migration path
Issue References:
Fixes #123
Closes #456, #789
Refs #111
Output Format
Provide 3 versions:
Version 1: Concise (Subject Only)
<type>(<scope>): <subject>
Use when: Small, obvious changes
Version 2: Standard (Subject + Body)
<type>(<scope>): <subject>
<body explaining what and why>
<footer with issue refs>
Use when: Regular commits with context needed
Version 3: Detailed (Full Format)
<type>(<scope>): <subject>
<detailed body with context>
<why this change was needed>
<what changed>
<breaking changes if any>
<issue references>
Use when: Significant changes, breaking changes, or complex features
Examples for Reference
Good Examples
feat(auth): add JWT token refresh mechanism
Implement automatic token refresh to improve UX by preventing
unexpected logouts. Tokens now refresh 5 minutes before expiry.
- Add refresh token endpoint
- Implement token expiry detection
- Add automatic retry with new token
Closes #234
fix(api): handle null response in user profile fetch
Previously, the app would crash when API returned null for missing
user profiles. Now shows appropriate error message instead.
Fixes #567
refactor(database): migrate from callbacks to async/await
BREAKING CHANGE: All database functions now return Promises instead
of using callbacks. Update all callers to use await or .then().
Migration guide: Replace db.get(id, callback) with
await db.get(id)
Bad Examples (Avoid These)
❌ Updated stuff
❌ fixes
❌ WIP
❌ Fixed the bug in the thing
❌ feat: Added new feature for users to be able to do something
Constraints
- Follow the specification exactly
- Subject line MUST be 50 characters or less
- Use imperative mood consistently
- Provide context in body for non-obvious changes
- Always reference issues when applicable
- Be specific about breaking changes
How to Use
1. Copy the prompt
2. Fill in 'Change Information' section
3. Be specific about what and why
4. Paste into AI tool
5. Choose from the 3 generated versions
6. Copy and paste into your git commit
How to Customize
• Add your team's custom types (e.g., 'security', 'deps')
• Specify your project's scope naming convention
• Add required issue tracking format (LINEAR-123, JIRA-456, etc.)
• Include team-specific commit message policies
• Add emoji conventions if your team uses them (:sparkles:, :bug:, etc.)
• Specify maximum subject line length if different from 50
Expected Outcome
Three commit message options:
1. Short version for quick commits
2. Standard version with context
3. Detailed version for complex changes
All following Conventional Commits spec with:
- Correct type and scope
- Imperative mood
- Clear body explaining WHY
- Issue references
Pro Tips
Think about future you reading git log in 6 months. The commit message should explain WHY you made this change, not just WHAT changed (the diff shows that). For breaking changes, always include migration instructions. Group related changes in one commit, don't make separate commits for each file.