When to use this generator
- Your team (or release tooling) expects Conventional Commits and you want a quick, valid shape before you paste into
git commit. - You are onboarding and need a template so subject lines stay short and scopes stay consistent.
- You are drafting a breaking change or issue footer (
Closes #…) and do not want to misplace the!orBREAKING CHANGEblock.
Real-world example
You fixed a login redirect after a deploy. You choose fix, scope auth, description redirect loop after OAuth callback, footer Fixes #412. The result matches what many changelog tools parse—copy it, review, commit.
Common mistakes
- Subject line novel: the first line should stay ~50 characters and imperative ("add", not "added").
- Wrong type for the work: tagging a refactor as
featbreaks release semantics. - Breaking flag without migration note: toggling breaking change but leaving reviewers guessing what broke.
Limitations of this tool
- It does not run git for you, enforce hooks, or know your team's custom commitlint rules.
- It won't validate that the described change matches the diff—always re-read before pushing.
- Breaking-change footers here are a starting point; production repos often require longer migration text.