Write a Clear Git Commit Message

This prompt turns a plain-English description of a code change into a clean, Conventional Commits–formatted message, complete with a typed subject line and a body that explains the reasoning. It's structured to enforce the parts developers most often skip: keeping the subject short and explaining WHY rather than restating the diff. Use it when you've made a non-trivial change and want a commit message that will still make sense to a teammate (or future you) six months from now.

What you can expect back

fix(auth): store session token in httpOnly cookie

The session token was previously kept in localStorage, which is readable
by any script running on the page and therefore exposed to XSS attacks.
The server now sets and clears the token as an httpOnly, Secure cookie,
and the client no longer reads or stores it directly.

BREAKING CHANGE: clients that read the token from localStorage will no
longer find it; the token is sent automatically with requests via cookie.

Illustrative example — your results will vary by tool and inputs.

Get sharper results

• 01Give it the actual scope (the module or package name) in your description, otherwise it guesses a generic scope like (app) that's less useful in a monorepo.
• 02Paste at least `git diff --stat` so the model picks the right Conventional Commit type — without it, refactors often get mislabeled as feat.
• 03If the change is genuinely trivial, tell it 'no body needed' so you get a one-line message instead of an invented paragraph.
• 04When you have several unrelated changes staged, ask it to split them into multiple commit messages so you can commit them separately and keep history clean.
• 05Add your team's allowed type list (e.g. feat, fix, chore, docs, refactor) if you use commitlint, so the output passes your CI hook on the first try.

Adapt it for your case