commit-messageSKILL.md · 654 B
A git log you can read back.
Ask for a commit message and the first thing it does is run git diff HEAD — reading the change before writing a word about it. What comes back is a subject line you can scan in a log, a paragraph on why the change was needed, and a list of what actually moved.
The order is the point. A message written from the session you just had describes the session, false starts and all. A message written from the diff describes the commit.
cp -r commit-message ~/.claude/skills/What it does
The first instruction in the file is the one doing the work.
Everything after git diff HEAD is a shape to pour the diff into: a title, a line of context, bullets for the changes, and a standing instruction to mention any file deleted or renamed — the one thing a diff never forgets and you always do. Because the bullets are read off the diff rather than recalled, they come back carrying specifics: the exact clamp(4.5rem, 6.9vw, 8rem) that replaced a fixed size ramp, the alias resolved through native resolve.tsconfigPaths support, the min_size_mb key a config rule now exercises.
The paragraph in the middle is the part no diff can supply, and it is why the message is worth keeping. “Mercury had no test infrastructure.” “The README and example config lacked a single factual snapshot of what fileorg can do today.” A year on, the diff is still there to read; the reason for it is not, unless someone wrote it down at the time.
The format names three sections: ## Title then ## Description then ## Changes — and not one of the three messages here carries those headings. They are scaffolding: the shape gets filled and the labels are dropped, so what lands in the log is a subject line, a paragraph and a list. Which is also why the file is 654 bytes. It is not a style guide, it is one instruction about what to read first.
Example messages
Three messages as the skill wrote them, from three different repos — a site, a weather app and a command-line tool.