changelog entry

Status: ready — not yet trained.

Traits

User Impact Focus

Frames change as user-visible impact or capability ↔ Describes internal implementation or invisible plumbing

Whether the entry communicates the change in terms of what users can now do or how their experience changes, versus describing internal implementation details, dependency bumps, or refactoring work invisible to users.

Specificity

Names concrete features, behaviors, or outcomes ↔ Vague or generic with no identifiable specifics

Whether the entry names concrete things — specific features, endpoints, error messages, workflows, or metrics — versus vague hand-waving like "improved performance" or "various bug fixes" with no anchor.

Actionability

Tells the reader what to do or what changed for them ↔ States a fact with no guidance on implications or next steps

Whether the entry tells the reader what they need to do or know — migration steps, new flags to set, deprecated paths to move off — versus leaving them to discover implications on their own.

Scoping

Single well-bounded change per entry ↔ Multiple unrelated changes lumped together or unfocused

Whether the entry is a single atomic change clearly bounded in scope, versus a kitchen-sink dump that rolls multiple unrelated changes into one bullet or buries the signal in a wall of text.

Motivation

Explains why the change matters or what problem it solves ↔ States what changed with no motivation or context

Whether the entry explains why the change matters — the problem it solves, the benefit it delivers, the context that makes it meaningful — versus just stating what changed with no rationale or connection to user needs.

About

Scores the quality of a changelog entry.

What it measures

Whether a changelog entry effectively communicates a product change to its audience — developers integrating an API, users checking what shipped, or team leads scanning for breaking changes. The model rewards entries that frame changes in terms of user impact (not internal plumbing), name concrete features or behaviors, explain why the change matters, and tell the reader what to do next (migrate, enable, deprecate). Kitchen-sink dumps that lump multiple unrelated changes into one bullet score low, as do entries that describe purely internal refactoring with no user-facing consequence.

Feed a single changelog entry as input text. For multi-entry changelogs, score each entry individually.

Limitations

• Optimized for user-facing product changelogs in English. Internal engineering notes or commit logs will score low by design — they shouldn't be in a user changelog.
• Does not judge formatting (markdown structure, Keep-a-Changelog headings) — only the content quality of the entry itself.
• Entries about genuinely internal changes (CI tweaks, test infrastructure) will score low; that's correct behavior.

Pairs well with

• u22a8.commit-message — score the commits that feed into changelogs
• u22a8.pr-description — the PR body where changelog-worthy changes first get described

Docs

• Tiers — categorical labels (Strong, Solid, Developing, Weak) assigned per trait
• Breaks — the per-trait trained boundaries between tiers