mcclain-thiel/omnisci/changelog

changelog — write a changelog from a commit/PR range

Turn a range of history into a clear changelog entry that a user can read to decide whether and how to upgrade.

Gather the range

Establish the range first. Honor an explicit one ("since v1.2.0", "the last 10 commits", "PRs merged this week"); otherwise default to commits since the most recent tag (git describe --tags --abbrev=0 then git log <tag>..HEAD).

Collect the raw material yourself with sys_os_shell:

• git log <range> --no-merges --pretty=format:'%h %s' for the commit subjects.
• git log <range> --merges or gh pr list --search "merged:>=<date>" for PRs.
• git diff <range> --stat to see the surface area, and gh pr view <n> for a

PR's intent when a subject line is terse.

When a subject is unclear about user impact, dispatch the researcher (purpose: explore) to read the diff and report what actually changed for users — do not guess from the subject alone.

Group by change type

Use the Keep a Changelog categories, dropping any that are empty:

## <version or range> — <YYYY-MM-DD>

### Added ### Changed ### Deprecated ### Removed ### Fixed ### Security

Write each entry

• One line per user-visible change, in the imperative or past tense, describing

the effect on the user — not the internal mechanics.

• Lead with the change, link the PR or commit in parentheses at the end.
• Omit pure-internal churn (refactors, test-only changes, CI) unless it changes

behavior. A changelog is for users, not a commit dump.

• Call out breaking changes explicitly and point to the migration-guide skill

if upgrade steps are needed.

Verify

Before finalizing, route the draft through the reviewer (purpose: review) when the changelog will ship — version numbers, "removed"/"breaking" claims, and flag names are exactly what a fact-check catches.