Conventional commits exist for changelogs and semantic versioning. feat: bumps a minor, fix: bumps a patch, tooling does the rest.
They are also, incidentally, the best structured signal a developer produces about the relative importance of their own work.
What the prefix gives you
feat(export): add CSV download
fix(auth): handle expired refresh token
chore(deps): bump next from 15.2 to 15.3
docs: update README
refactor(api): extract client builder
Five commits, five different answers to "is this worth a post". And you get that answer without parsing English, which is the expensive and unreliable part.
Rough ordering by content value:
featis a new capability. Almost always postworthy.fixis a bug. Good material if it was interesting, which the message alone will not tell you.perfis a measurable improvement. Strong material because it often comes with numbers.refactoris internal. Occasionally interesting as a "why we changed this" post.docs,test,style,build,ci,choreare almost never on their own.
The scope is the more useful half
The part in parentheses is more valuable than the type, because it groups.
feat(export), fix(export) and test(export) are three commits about the same piece of work. A scope match is the strongest available grouping signal, stronger than shared files, because the author asserted it deliberately.
It also works as a veto. Two commits with different explicit scopes should not be merged on circumstantial evidence like touching a shared utility file. We learned that the hard way: without the veto, one transitive chain through src/lib produced a single forty commit "story" covering three unrelated features.
The trap
Dependabot's canonical format is:
chore(deps): bump next from 15.2.3 to 15.3.0
Type is chore, so a naive filter drops it. Correct, in this case.
But scope deps should also mark a commit as noise even when the author writes fix(deps): bump lodash. That one has type fix, survives a type-only filter, and is exactly as uninteresting.
So scope has to override type for deps, dependencies, deps-dev and dev-deps. This was a real bug in Noomachy DevTracker: dependency bumps were showing up in draft posts because the most common form of them wore a fix label.
If you do not use conventional commits
You can infer most of it from ordinary messages. "Added", "Created", "Implemented" suggest a feature. "Fixed", "Resolved" suggest a fix. "Bump", "Update dependency" suggest noise.
It works reasonably and it is clearly worse. English is ambiguous in ways prefixes are not. "Fix typo in the docs" and "Fix the race in the scheduler" are both fixes and only one is worth writing about, and nothing in the grammar distinguishes them.
Ordering matters when you do this. Check specific markers before generic verbs: "add coverage" should classify as test, not feature, and "fix typo" should classify as docs, not fix. Match on add first and both go wrong.
The argument for adopting them
If you already write commits carefully, prefixes cost you nothing and give every downstream tool a clean signal. Changelog generation, release automation, and, as it happens, deciding which afternoon of your week was worth telling anyone about.