Why it is written this way
If you only explain rules conceptually, the AI will return slightly different formats each time—one day fix: ..., the next day [Fix] ..., sometimes just a title, and sometimes five bullet points. The moment formatting becomes inconsistent, repository history gets much harder to scan.
That is why the second paragraph provides two concrete examples alongside the rule description. Just like humans, AI follows a fully realized sentence much better than abstract instructions like "under 50 chars, imperative mood." Providing two examples prevents the model from overly anchoring on the topic of a single example.
In the Task, specifying that the 3 options must have "distinctly different perspectives" prevents the model from merely returning three nearly identical variations with slight wording tweaks. The Format requirement to explain "why it changed" defines the purpose of the body. Reviewers can already read the diff to see what changed; the commit log exists to preserve the reasoning.
Setting the Context by stating that "someone will read this months from now to understand why this line changed" guides the tone, vocabulary, and length. Without this, the AI tends to generate vague titles or internal abbreviations understandable only today.
Lastly, the Constraint to "never fabricate issue numbers" prevents AI hallucination. Wrapping the diff with """ ensures that comments and strings inside the code are not misinterpreted as prompt instructions.
Unfamiliar terms? See Aha AI: few-shot, output-format
Compared with a bad example
Write a commit message for this.
(pasted diff)
You will likely get a generic one-liner like "Update cart.js" or an itemized list that simply repeats the changed lines verbatim. Without rules or context, prefix conventions and tone will fluctuate, and the underlying "why" is lost.
Variations
When a diff contains multiple unrelated changes
Please first evaluate whether the changes below contain multiple unrelated tasks. If so, suggest how to split them into separate commits in the format of "Commit Order · Included Changes · Suggested Title". If splitting is unnecessary, let me know that a single commit is sufficient. Follow this rule: {{message rule}}.
""" {{change details}} """
Use this when you have batched too much work into one staging area and need guidance on clean, reviewable commit boundaries.
When strict English commit conventions are needed
Please generate 2 English commit message candidates based on the changes below. The title must be in imperative present tense and within 50 characters, and the body must be hard-wrapped at 72 characters per line. Follow the rule: {{message rule}}. Use clear, standard developer terminology rather than verbose phrasing.
""" {{change details}} """
Useful for open-source contributions or international team repositories. Specifying the 72-character line wrap prevents formatting breaks in terminal logs.
Model notes
If the diff is very long, split it by file and ask the model to combine them into a single commit message at the end.
When pasting raw diffs, the heavy use of symbols (+, -) can sometimes cause the model to invert the direction of the change. Adding a single summary line at the top, such as "Summary of this change: ...", significantly improves accuracy.
Related prompts
Last updated 2026-09-02 · Found a mistake? Let us know