Commit Log to User Changelog
Stop writing "fixed a null check." Start writing what actually broke.
Commit Log to User Changelog
Engineers write commit messages for engineers. Changelogs are for users. These are fundamentally different documents — but LLMs produce the former when asked for the latter.
Given a list of commits like:
A model without optimization writes:
That's not a changelog. That's a lightly paraphrased commit log. Users don't know what "session middleware" is. They want to know: did something break? is it fixed? what can I do now that I couldn't before?
A real changelog entry for that first commit: "Fixed a crash that could occur when your session expired mid-checkout."
This example optimizes the translation from technical cause to user impact.
Optimizer: ContraPromptOptimizer
Difficulty: Intermediate
Full Example
The Register Problem
The failure here isn't factual — it's register. Technical and user-facing writing describe the same event in different vocabularies:
| Technical | User-facing |
|---|---|
| null pointer dereference | crash |
| race condition | intermittent bug |
| HTTP 429 rate limit | the feature stopped working |
| XSS sanitization | display issue |
| connection pool deadlock | request failures |
The model defaults to the technical register because commit messages are its input. ContraPromptOptimizer is well-suited here — it mines pairs where technical register leaked through vs. where it didn't, and extracts a rule about vocabulary substitution and perspective shift.
The metric's feedback field includes a concrete example of the target register
(example['good_entry']). This is deliberate: when the feedback shows rather than
just tells, the optimizer generates more specific, transferable rules.