What this prompt does
This prompt generates a conventional commit message from a diff in a [project_type] that follows [commit_convention] and touches [scope_area]. It does more than label the change — it classifies the type, writes an imperative subject, explains the why in the body, and flags problems in the diff before they land.
The structure works because it encodes commit discipline as rules. It picks the most specific type — feat, fix, refactor, docs, test, chore, perf, or style — from the diff's primary intent, then writes a type(scope): description subject under [char_limit] characters in imperative mood. The body, at the [body_detail_level] you set, explains why the change was necessary and which alternatives were rejected. Footer references use your [footer_format], BREAKING CHANGE is added when warranted, and if the diff mixes concerns it suggests splitting into up to [max_commits] ordered commits. It also flags debugging code, commented-out blocks, and stray TODOs that should not be committed.
When to use it
- You work in conventional-commit repos and want consistent
type(scope)subjects. - You want commit bodies that explain why, so git history stays searchable later.
- Your diff mixes concerns and you want it split into clean commits.
- You need a quick check for debugging leftovers before committing.
- You want footer references in your
[footer_format]for issue tracking. - You need BREAKING CHANGE flagged when a diff breaks compatibility.
Example output
Expect a formatted commit message ready to drop into your editor. The subject line reads type(scope): description in imperative mood and stays under [char_limit] characters, answering what the commit does rather than what you did. Below a blank line sits a body written at your [body_detail_level], explaining why the change was necessary, what approach was chosen, and which alternatives were rejected. Footer references follow your [footer_format], with a BREAKING CHANGE note added when the diff breaks compatibility and a Co-authored-by line for pair work. If the diff bundles unrelated changes, you also get a suggestion to split it into up to [max_commits] ordered commits, plus warnings about any debugging code, commented-out blocks, or stray TODOs the diff would otherwise commit.
Pro tips
- Set
[char_limit]to your team's real subject cap (often 72) so the subject does not get truncated in tooling. - Keep
[body_detail_level]honest about scope — a short, focused body that explains why beats a long one that restates the diff. - Let it split tangled diffs; landing up to
[max_commits]single-concern commits keeps history bisectable. - Match
[footer_format]to your tracker (Closes #123 or a Jira key) so issues link automatically. - Trust the leftover-detection step; catching commented-out code and stray TODOs before they land saves a cleanup commit later.
- Make sure the chosen type reflects the primary intent — a fix bundled with a refactor should usually be two commits.
