Git Commit Message Writer
The Git Commit Message Writer generates properly formatted commit messages from your code diff or change description. It follows the Conventional Commits specification and focuses on explaining the "why" behind changes, not just the "what".
Developers of all levels use this template when they have made changes but struggle to articulate them concisely, when they want to maintain a consistent commit history for their team, or when preparing squash commits that summarize multiple changes. It is especially helpful for open-source contributors who need to match a project's commit style.
The prompt enforces a specific structure (type, scope, description, body, footer) that makes git history searchable and useful. It also generates breaking change notices and issue references when applicable, which many developers forget to include.
This prompt is just the starting point
Score it with AI, optimize it with one click, track versions, and build your prompt library.
The Prompt
Write a git commit message for the following changes:
**Changes Made** (paste your git diff or describe what changed):
```
[PASTE YOUR GIT DIFF OR DESCRIBE THE CHANGES]
```
**Context** (optional but recommended):
- Why was this change made? [REASON FOR THE CHANGE]
- Does this fix a bug, add a feature, or refactor existing code? [TYPE OF CHANGE]
- Related issue or ticket number: [ISSUE NUMBER, e.g., #123 or JIRA-456]
Generate the commit message following this format:
```
type(scope): short description (max 72 chars)
Longer explanation of what changed and WHY (not just what).
Wrap at 72 characters per line.
- Bullet points for multiple related changes
- Focus on motivation and context, not implementation details
Refs: #issue-number (if applicable)
BREAKING CHANGE: description (if applicable)
```
Type must be one of: feat, fix, refactor, docs, test, chore, perf, style, ci, build.
Rules:
- Subject line must be imperative mood ("Add feature" not "Added feature")
- Subject line must not exceed 72 characters
- Do not end the subject line with a period
- Body should explain WHY, not WHAT (the diff already shows what)
- If the change is trivial (typo fix, formatting), a subject line alone is sufficient
- Include BREAKING CHANGE footer only if the change breaks existing behavior
Provide 2 options: one concise (subject only) and one detailed (with body).Usage Tips
- Paste the actual diff: Running
git diff --stagedand pasting the output gives much better results than describing changes in English. The AI can read diffs accurately. - Always include the "why": Fill in the reason placeholder even briefly. "Fixed because users reported 500 errors on login" produces a much better commit than "Fixed login".
- Choose the right type: Use
featfor new user-facing functionality,fixfor bug fixes,refactorfor code changes that do not change behavior, andchorefor maintenance tasks. - Adapt to your team's convention: If your team uses a different format (e.g., no scope, different types), mention it in the context section.
Get more from this prompt
Save it, score it with AI, optimize it, and track every version. Free to start.