Conventional commit message prompts

Most engineers spend the same five seconds writing the same generic commit message — update X, fix Y, refactor Z. Then the next reader has to open the diff to understand what actually happened. A two-line commit message would have answered the question.

The fix is one of the smallest, highest-ROI prompts in the whole course. You give the model a diff. It returns a conventional commit message that follows your team's format.

Write a single conventional-commit message for this diff. Subject line under 60 chars. Then a 1-2 sentence body. Then a "BREAKING CHANGE:" footer if applicable.

Diff:

- export type Order = { id: string; total: number; }
+ export type Order = { id: string; totalCents: number; }

(All call sites updated to read totalCents and divide by 100 at the UI boundary.)

Claude Sonnet 4.5 returned:

refactor(order)!: rename total to totalCents for clarity

The Order type now uses totalCents instead of total to make the unit
explicit. All call sites have been updated to use totalCents and
handle currency formatting at UI boundaries.

BREAKING CHANGE: Order.total has been renamed to Order.totalCents. Consumers must update property access and divide by 100 for display.

Captured from Claude Sonnet 4.5 (claude-sonnet-4-5) on 2026-04-27. Re-runs may differ slightly.

The output is publishable. The subject line is 51 characters and includes the conventional refactor(order)!: prefix with the breaking-change !. The body explains the why in two sentences. The BREAKING CHANGE: footer is exactly the format git log parsers and changelog tools expect.

Three things this prompt does well:

What	Why
under 60 chars constraint on subject	Avoids GitHub truncation in the commit list
1-2 sentence body	Body is rich enough to be useful, short enough to read
BREAKING CHANGE: footer if applicable	Lets the model omit it for non-breaking changes

The "if applicable" wording is doing more work than it looks. Without it, the model includes a BREAKING CHANGE: footer for every commit (because the prompt mentions it), which makes downstream tooling treat every commit as breaking. With it, the model only includes the footer when the diff actually breaks something.

The diff → conventional commit pipeline:

This prompt scales beautifully. Wire it up as a prepare-commit-msg git hook or a CLI shortcut, and your commits go from 1-line generic to 4-line specific without you spending more time. You stop writing update util forever.

A useful next step: chain this prompt with the PR description prompt from module 3. The conventional commit message becomes the PR title; the body becomes the ## Summary section. One round-trip, two artifacts.

A subtle warning: the model sometimes invents details from the diff that aren't actually in the change. In the captured output, the line "All call sites have been updated to use totalCents" is provided in the prompt parenthetical, so it's faithful. If the model wrote that without you having said it, you'd want to verify. Always read the body before committing — it's a 3-second sanity check that catches the rare hallucination.

The other shape of this prompt that engineers love: ask for just the subject line, no body. Useful for tiny commits where a body is overkill:

One-line conventional commit subject for this diff. Under 60 chars. No body.

Now your every-commit prompt is one short input → one short output. The mental cost is gone. The information density of your commit history goes up.

Module 6 next: the capstone — Karim ships a real PR. :::