Back to Prompts

Conventional Commit Message Generator

GitVersion ControlConventional CommitsBest Practices
Added: January 2, 2026Difficulty: BeginnerWorks 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.