I don’t get these kind of tools. A commit should be the why of a change, not a summary of what it is, anyone can either get that themselves or just read the code if they desire. What you can not get from the code is the _why_ which only you as the author can put.
I often start a change by having Cursor read the Slack thread (via MCP) that is motivating the change. In the same Cursor thread, after making the change, it has fairly good context on the _why_ and writes a helpful commit message.
Very nice, the fewer neurons you use the better. In biology they call it use it and lose it if my memory serves me correctly.
Neurons that fire together, fry together.
While I’m deeply skeptical of any attempt to define a commit message from the diff, if the context and motivation is truly captured in the Slack thread or other prior documents and available for summarization, then how many neurons are you really using on rewording what you already hashed out? Especially if someone would otherwise perhaps skip a message or write a poor one, this sounds like a great approach to get at least a first pass to further modify.
There are plenty of commits that don't need an explanation like mechanical cleanups or refactoring. If your code is appropriately documented then an LLM can often extract the explanation too.
If there truly is no need for an explanation, the commit message is very short and won’t require any substantial effort on the author to write.
A fix often has a particular bug it’s addressed, the bug should be explained in the commit. A refactor has a reason, that needs to be explained as well.
I’m not saying LLMs can’t do this, but it needs the context and it’s rarely in the diff of the commit you will find that.
I do often ask Claude Code or Gemini CLI to write commits. I agree with you on why being important. Majority of these being bug fixes accompanied tests where the why is easily inferred from the change/newly added tests and their comments.