Write a commit message

A Conventional Commits message that describes the behaviour change and why — the version future-you reads in the history, not a list of files.

When to use it

Any commit whose message will outlive the diff — a squashed PR, a change that feeds a changelog, anything future-you will read while bisecting a regression.

What it prevents

The message that says what a diff already shows. “Updated auth.ts” is visible in the diff; what the diff cannot tell you is why, or that the behaviour changed for expired tokens. Directing the model at the why and the behaviour change is what makes the history worth reading.

The prompt

Write a git commit message for the diff summary below.

### Context
The team follows Conventional Commits and squashes pull requests, so this message is what lands in the main branch history and feeds the changelog generator.

### Requirements
- Output format: A subject line under 50 characters, a blank line, then a body wrapped at 72 characters.
- Subject: type(scope): imperative summary. Body: what changed and why, not how.
- Flag any breaking change in a dedicated footer line, following the Conventional Commits spec.
- Do not list files; describe the behaviour that changed.
- Avoid: "misc fixes", "updates", and the past tense in the subject.

### Diff summary
"""
Reject expired tokens in auth middleware; previously only malformed ones were rejected.
"""

Why each part is there

Every section of that prompt exists because a specific failure happens without it. These are the checks it passes, and what each one is protecting you from:

• States a concrete task — why this matters
• Avoids vague language — why this matters
• Specifies an output format — why this matters
• Gives context or audience — why this matters
• Avoids dangling references — why this matters
• Avoids over-aggressive phrasing — why this matters
• Defines what a good answer looks like — why this matters

How to adapt this one

Give it the real change and keep the convention your team uses — Conventional Commits here, but swap in yours. Keep the “why, not how” rule and the breaking-change footer; a breaking change buried in a body is a breaking change nobody sees until it breaks them. The subject-length cap matters more than it looks: it forces the summary to be a single clear claim.

The mistake this prompt avoids

Describing the files instead of the behaviour. “Changed the middleware and a test” lists what moved; “reject expired tokens, not just malformed ones” states what now behaves differently. The history is read by someone hunting a regression — they need the behaviour that changed, which is the one thing the diff makes hardest to see at a glance.

A variation

Writing a pull-request description rather than a single commit? Ask for the same why-focused summary plus a short “how to verify” section — the steps a reviewer runs to confirm it works. A commit message explains the change to the future; a PR description also has to get it reviewed in the present, and that needs a way in for the reader.

Check your version

Once you have adapted it, run it through the checker. The same nine checks that graded this page will grade yours, free and in your browser — paste it in, or build one from scratch by answering a few questions.