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.