Prompt

Git Commit Message Writer

gitversion controlworkflow

Git Commit Message Writer: Professional Commits Every Time

Clear commit messages make your git history readable and useful. This tool generates conventional commit messages that follow industry best practices.

Full Prompt
Generate a precise, well-structured git commit message following the Conventional Commits specification that clearly communicates what changed and why.

COMMIT MESSAGE GUIDELINES:

1. Determine the Commit Type
   - feat: A new feature visible to users or downstream consumers
   - fix: A bug fix (reference the bug or symptom being resolved)
   - docs: Documentation-only changes
   - style: Formatting, whitespace, semicolons (no logic change)
   - refactor: Code restructuring with no behavior change
   - perf: Performance improvement
   - test: Adding or correcting tests
   - build: Changes to build system or dependencies
   - ci: Changes to CI configuration or scripts
   - chore: Maintenance tasks that do not fit other types

2. Determine the Scope
   - Identify the module, component, or area affected (e.g., auth, api, db, ui, payments)
   - Use lowercase, hyphenated names
   - Omit scope only if the change is truly cross-cutting

3. Write the Subject Line
   - Use imperative mood ("add" not "added" or "adds")
   - Do not capitalize the first letter after the colon
   - Do not end with a period
   - Keep under 72 characters total (including type and scope)
   - Be specific: "fix null pointer in user lookup" not "fix bug"

4. Write the Body (when changes are non-trivial)
   - Explain WHAT changed and WHY, not HOW (the diff shows how)
   - Reference the problem or motivation that led to this change
   - If there are multiple logical changes, consider whether this should be multiple commits

5. Write the Footer (when applicable)
   - BREAKING CHANGE: description (if the change breaks backward compatibility)
   - Refs: #issue-number or ticket ID
   - Co-authored-by: if applicable

OUTPUT CONSTRAINTS:
- Always output the commit message in a copy-paste-ready code block
- If the changes described suggest multiple unrelated modifications, recommend splitting into separate commits and provide a message for each
- Subject line must be under 72 characters
- Body lines should wrap at 72 characters
- If the changes are trivial (typo fix, single-line change), a subject-only message is fine; do not add an unnecessary body

FORMAT:
```
type(scope): subject line

[Body paragraph explaining what and why, if non-trivial]

[Footer with references or breaking changes, if applicable]
```

---

MY INFO:

Changes Made: (required - describe what you changed and why)

Issue/Ticket Number: (optional)

Breaking Changes: (optional - describe any backward-incompatible changes)

Conventional Commits Format

<type>(<scope>): <description>

[optional body]

[optional footer]

Commit Types

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation changes
  • style: Code style (formatting, semicolons)
  • refactor: Code refactoring
  • test: Adding tests
  • chore: Maintenance tasks

Good vs Bad Commits

Bad: "fixed stuff" Good: "fix(auth): resolve token expiration issue on refresh"

Benefits of Good Commit Messages

  • Searchable git history
  • Automatic changelog generation
  • Clear code review context
  • Easy rollback identification

Write commits that tell a story about your codebase evolution.