Diff → Conventional Commit Helper
Paste a git diff and automatically infer type/scope from the changed files to generate a commit message template. Supports Conventional Commits format, validates subject line at 50 characters, detects BREAKING CHANGE, and generates a prompt ready to send to AI.
📋 How to capture diff
# Everything that changed git diff # Only what is staged git diff --cached # A specific commit git show abc123 # Filenames only, when the diff is too large git diff --stat
📖 Where people get stuck
Paste the output of git diff and this infers a type and a scope from the changed files and the line counts, then assembles a Conventional Commits template and a prompt you can hand to an AI. Everything runs in the browser. What can be inferred is what changed; why it changed appears nowhere in a diff — and the second is always what the person reading it later actually wants.
| Case | What happens | What to do |
|---|---|---|
| The inferred type is wrong | The type is inferred from paths and extensions, so it cannot distinguish two different intents behind edits to the same place. Touching test files suggests test, but if you were updating expectations alongside a bug fix, fix may be the honest label. The line between docs and chore, or refactor and fix, is equally invisible in a diff. |
Take the inference as a starting point and always override it yourself. The test when you are unsure is whether the behaviour changed from the user point of view. If it did, feat or fix; if it did not, refactor, chore, test or docs. That rule pays off directly when you generate release notes — only the changes worth showing users land in the first two, so nobody has to sort them by hand later. |
| One commit carrying several changes | When the inferred scope comes out as (*) or as a list, that is a signal the commit is too large. With a bug fix, a refactor and a dependency bump in one commit, a later git revert takes back the parts you wanted to keep as well. It also blunts git bisect: the larger the commit it lands on, the less it has narrowed anything down. |
Use git add -p to stage hunk by hunk and commit one meaning at a time; you can split a working tree that already mixes them this way. The test is whether you can describe the commit in one sentence — if the sentence needs an "and", split it. Paste each split diff into this page separately and you get a template for each. |
| The AI only gives you a summary of the diff | Hand over the diff alone and the model can only see the change in the code. What comes back is a restatement of what the diff already shows — added this, fixed that. The value of a commit message lies in recording what the diff cannot tell you, so a message like that has not earned its place. | Add one or two lines in your own words about why you made the change before handing the generated prompt over. A single external fact — three timeout reports a month, a tax rate changed by legislation — changes the quality of what comes back. Adding the related issue number lets whoever reads it in six months follow the whole trail. The prompt library has templates worth borrowing from. |
The practical payoff of Conventional Commits is that a changelog and a version number can be generated from the messages: tools such as semantic-release map fix to a patch, feat to a minor, and anything carrying BREAKING CHANGE to a major. The converse is that a single non-conforming commit makes that release automation untrustworthy. If you adopt it, put commitlint in a pre-commit hook and let a machine enforce the format — a convention held together by good intentions alone is not something anyone has ever seen last.
❓ Frequently Asked Questions
How is type detected?
Need AI?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.