CLI that turns LLM input into well-formatted Conventional Commits
docs: don't bury the lede, polish
+18
-6
+18
-6
README.md
+18
-6
README.md
···
10
10
11
11
[](https://goreportcard.com/report/git.secluded.site/formatted-commit)
12
12
13
-
CLI tool that requires conformance with the Conventional Commits specification
14
-
through flags, made for LLMs and not really for the operators (but I guess you
15
-
can use this directly if you want). Operators would likely prefer, as the author
13
+
CLI tool that produces commits following the Conventional Commits specification
14
+
through flags, made for LLMs and not really their operators (but I guess you can
15
+
use this directly if you want). Operators would likely prefer, as the author
16
16
does, [meteor](https://github.com/stefanlogue/meteor).
17
17
18
-
`formatted-commit` enforces a 50-character subject limit and sanitises/wraps the body at 72
19
-
characters. I might make that configurable. Idk. It's a loose standard held by
20
-
projects like the Linux kernel and I try to stick to it.
18
+
I've found that LLMs consistently fail to
19
+
20
+
- Format trailers correctly: they add too many newlines between trailers, which
21
+
breaks tools like `git interpret-trailers`
22
+
- Include proper scope notation
23
+
- Follow the loose 50/72 subject/body standard held by projects like the Linux
24
+
kernel. I try to stick to it, but LLMs writing badly-formatted commit messages
25
+
means rewording work for me once they're done.
26
+
27
+
`formatted-commit` enforces all of this. Where possible, we "correct" the
28
+
model's input. Where that's less possible, we error. For example, instead of
29
+
requiring the model wrap body text at 72 columns, we let it write whatever body
30
+
it wants and wrap it ourselves. We can't really fix the subject, so
31
+
`formatted-commit` emits an error when the subject is too long with clear
32
+
indication of where the 50-character cut-off is.
21
33
22
34
## Installation
23
35