Writing good commit messages is a skill, but writing them consistently across a team is a system. These Git Commit Message Prompts solve the exact problem of vague, useless commit history by turning your diff into a structured, review-ready narrative. I use these daily with Claude, GPT-4, Gemini, and DeepSeek, and they all handle the templates well with minor tweaks.
Why Generic Prompts Fail Here
Most developers try "write a commit message for this diff" and get back a verbose essay that reads like a changelog. The failure mode is that LLMs default to describing what changed (files, functions) rather than why it changed. A generic prompt ignores your team's conventions, skips the impact analysis, and produces messages that are useless for git bisect or a future git log --oneline scan.
These templates force the LLM to think like a maintainer, not a code summarizer. They inject constraints: scope, type, breaking changes, and test status. Without that structure, you get "updated user service" instead of "fix: validate email format before OAuth redirect to prevent account takeover".
Template 1: The Conventional Commits Enforcer
This is my default for daily work. It forces the LLM to classify the change correctly and extract the reason from the diff, not just the diff itself.
You are a senior engineer writing a git commit message. Analyze the provided diff.
Constraints:
- Use Conventional Commits format: <type>(<scope>): <subject>
- Types allowed: feat, fix, refactor, chore, docs, test, perf
- Subject must be under 50 characters, imperative mood, no period
- Body must explain WHY the change was made (2-3 bullet points), not just what changed
- Include a "BREAKING CHANGE:" footer ONLY if the diff alters public API signatures or removes existing behavior
Diff:
<PASTE_DIFF_HERE>
Output ONLY the final commit message. No preamble, no commentary.
Placeholders explained:
<PASTE_DIFF_HERE>— yourgit difforgit diff --stagedoutput. The more context you give (including the previous function), the better the "why" extraction.- The type list is restrictive. If the LLM tries to invent "update" or "modify", it fails the constraint — retry or adjust the list.
Template 2: The Context Injector for Multi-File Diffs
When a change touches 15 files across 3 modules, the LLM loses the plot. This template forces a summary of the intent before drafting the message.
Act as a technical writer specializing in commit hygiene. Given this diff, generate a commit message.
You must:
1. First list the top 3 logical changes in the diff (one line each)
2. Then write the commit message based on those changes
3. Use this format: <type>: <subject> | <body with context>
4. If the diff includes deleted files, add "chore: remove dead code" as a separate line in the body
5. Never mention line numbers or file paths in the subject
Diff:
<PASTE_DIFF_HERE>
Return:
[Logical Change 1]
[Logical Change 2]
[Logical Change 3]
---
[Commit message]
This works better than Template 1 for large refactors because the "logical changes" step makes the LLM group related hunks. Without it, you get a Frankenstein message that mixes an API change with a CSS tweak.
Template 3: The Edge-Case Handler for Reverts and Hotfixes
This is for the messy days: reverting a broken merge, fixing a hotfix that broke staging, or committing a workaround. It forces the LLM to be brutally honest about the trade-offs.
You are reviewing a diff that is likely a hotfix or revert. Write a commit message that prioritizes operational clarity over brevity.
Rules:
- Start with either "revert:" or "fix(regression):" — determine which based on the diff
- If the diff removes more lines than it adds, assume it's a revert and explain what the original change was trying to do
- In the body, include a "Risks:" section listing 1-2 potential side effects of this change
- Do not use the word "fixes" — use "resolves" or "addresses"
- Keep the subject under 60 characters, but the body can be up to 10 lines
Diff:
<PASTE_DIFF_HERE>
Output ONLY the commit message.
This template shines when you're debugging at 2 AM. The "Risks" section forces the LLM to think about what could break next — something a generic prompt never does.
How to Adapt These for Your Own Codebase
First, replace the type list in Template 1 with your team's actual prefixes (e.g., db:, ui:, api:). Second, add a rule that references your ticket system — for example, "prepend JIRA-123: to the subject if the diff mentions a function named after a ticket ID."
Third, pipe the diff through git diff --stat first so the LLM sees the file size distribution — this prevents it from over-weighting a one-line change in a huge file. Fourth, if your team uses conventional commits with a scope, hardcode the scope list (like feat(auth):) into the template so the LLM doesn't guess.
Do These Prompts Work With Any LLM?
Yes, but with a caveat. Claude 3.5 Sonnet handles the multi-step reasoning in Template 2 best. GPT-4 Turbo is more literal and needs the "Output ONLY" instruction to avoid commentary. Gemini often ignores the "no line numbers" rule — you'll need to add "strictly forbidden" to that constraint. DeepSeek is fine but tends to write longer subjects; add a hard character limit to the prompt if that bothers you.
The single adjustment that improves all three templates the most: paste the previous commit message from the same file as context. It teaches the LLM your team's tone and structure in one shot — better than any instruction you can write.