Draft commit messages and PR descriptions from your diff
Good commit messages and pull request descriptions are how a change explains itself to reviewers now and to whoever debugs it in two years. But at the end of a long task, writing the why instead of the what is the corner almost everyone cuts. Summarizing recent code changes is a top-five AI task; feeding the diff to a model gets a structured draft you then edit for the reasoning it cannot see.
You are helping me write a clear commit message and pull request description from a diff. Follow my team's conventions. Commit convention (for example Conventional Commits) or "none": {{convention}} Why I made this change — the intent a diff cannot show: {{intent}} The diff: {{diff}} Produce two things: 1. A commit message: a concise subject line (imperative mood, about 50 characters, following {{convention}} if given), a blank line, then a body explaining what changed and why, wrapped at 72 characters. Reference the issue as "[ISSUE]" for me to fill in. 2. A PR description: a one-paragraph summary, a bulleted list of the notable changes, a "How to test" section, and a "Risk / rollback" note. Rules: - Describe only what is actually in the diff. Do not claim tests were added, docs updated, or a bug fixed unless the diff shows it. Mark anything you cannot confirm from the diff as "[VERIFY]". - The why must come from my intent notes, not from your guess about my motivation. - No filler, no restating the code line by line, no marketing tone.
Fill in your details and the prompt updates live — then copy.
feat(api): cache user permission lookups Permission checks hit the DB on every request, adding latency. Cache resolved permissions per user for 60s to cut redundant queries. Closes [ISSUE]. --- PR summary: Adds a short-lived in-memory cache for permission lookups. Notable changes: - New PermissionCache with a 60s TTL - Cache invalidated on role change How to test: call /me twice; the second call should skip the DB (see the debug log). Risk / rollback: cache is behind the PERM_CACHE flag; disable to revert. [VERIFY] invalidation on multi-instance deploys.
The full workflow
- Stage the final diff and jot one line on why the change exists
- Generate the message and description, then correct anything the diff does not actually support
- Fill in issue numbers and any "[VERIFY]" flags by hand
- Keep the reasoning in the body — that is the part reviewers and future-you actually need
Watch out for
A model summarizing a diff will happily claim you added tests or fixed a security issue you did not — a commit history is a permanent record others rely on, so verify every claim against the diff before committing.
Diffs can contain secrets, keys, or internal identifiers. Do not paste them into a consumer tool; use an approved integration or scrub them first.
The model sees the what but not the why. Supply the intent yourself, or you will ship messages that describe the change without explaining the decision behind it.
Where this comes from
Every use case on this site is grounded in real reports from working software developers — not invented by us.