Coding
AI Prompt for Detailed Commit Messages
Write detailed commit messages with this AI prompt: structured body with context, approach, and verification for changes reviewers need to understand.
The prompt
Role: You are a tech lead who documents significant changes so the team understands them months later. Context: Convention: [CONVENTION]. Diff summary: [DIFF] Background and intent: [INTENT_AND_CONTEXT] How I verified it: [VERIFICATION] Task: Write a complete commit message: 1) Subject line (type(scope): imperative summary, ≤72 chars). 2) Body paragraphs: the PROBLEM/CONTEXT (why this change exists), the APPROACH (key decisions and alternatives considered), and SCOPE NOTES (what this deliberately does NOT do). 3) A "Test plan" section from [VERIFICATION]. 4) References (issue numbers, related PRs) placed correctly per [CONVENTION]. Format: Full message in a code block, ready to paste into git commit. Ask the AI to draft the 'what this deliberately does NOT do' section with extra care — scope notes prevent future developers from assuming the change covered more than it did. Constraints: Answer "why" three times over — future readers need motivation, not mechanics. Keep each paragraph focused. If the change is actually two changes, say so and draft both messages.
Variables to fill in
Replace each [variable] in the prompt with your own details:
[CONVENTION] [DIFF] [INTENT_AND_CONTEXT] [VERIFICATION]
Example input
DIFF=large refactor of payment module: extracted gateway interface, moved Stripe logic, updated 12 call sites, INTENT=prepare for adding PayPal
How to use this prompt
Use this for refactors, features, and anything reviewers need context for. Give the intent — the body explains the why that the diff cannot show.
Tips for the best results
- The 'what this does NOT do' section prevents future confusion about scope.
- Link the issue number — it connects the commit to the discussion that motivated it.
- Ask the AI to draft the PR description from the same material next.
Frequently asked questions
When do I need the long format?
It structures the narrative (context → changes → verification) so reviewers understand a big change in one read.
When is a long commit message overkill?
For trivial changes — a clear subject suffices. Reserve the full structure for refactors, features, and anything a reviewer needs context to approve.