release-changelog

Generate stable Todero release changelogs from commits, changesets, and merged PRs.

Updated Mar 26, 2026
One-click install
npx skills add https://github.com/nabitllc/todero --skill release-changelog-nabitllc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: release-changelog
Source: https://github.com/nabitllc/todero/tree/main/.agents/skills/release-changelog
Command: npx skills add https://github.com/nabitllc/todero --skill release-changelog-nabitllc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing accurate, user-facing release notes for a calendar-versioned project requires manually reconciling commits, changesets, merged PRs, and beta soak state, which is error-prone and easy to get wrong. ## Core Features & Use Cases - Stable Range Resolution: Computes the changelog range from the last stable tag to the beta source commit, never from master HEAD, so post-beta commits are excluded. - Breaking Change Detection: Scans migrations, schema diffs, API routes, and commit messages for breaking changes and requires an upgrade path for each. - Structured Changelog Output: Produces a categorized markdown file (Breaking Changes, Highlights, Improvements, Fixes, Upgrade Guide, Contributors) with inline PR and contributor attribution. - Release Case Upsert: Optionally upserts a release Case via the Todero API and writes the changelog body as a document revision. - Use Case: A maintainer promoting a soaked beta to stable asks the agent to draft the release notes; the skill checks idempotency, gathers inputs, writes releases/beta/v{version}.md at full stable depth, and presents it for sign-off. ## Quick Start Generate the stable changelog for the upcoming Todero release by reading commits and changesets since the last stable tag.

Frequently Asked Questions about release-changelog

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate a release changelog from git commits?

Determine the range from the last stable tag to the beta source commit, then collect commits, changesets, and merged PRs in that range. Categorize entries into Breaking Changes, Highlights, Improvements, and Fixes, and write them from the user perspective.

How do I detect breaking changes before a release?

Diff migration directories, database schemas, and API route files between the last stable tag and the release commit. Also grep commit messages for BREAKING CHANGE markers or conventional-commit bang suffixes, and document an upgrade path for each finding.

What is calendar versioning and how does it differ from semver?

Calendar versioning derives the release version from the intended release date plus a same-day patch slot, such as 2026.318.0. Unlike semver, there are no major, minor, or patch bumps derived from API intent, so versions must never be inferred from changeset bump types.

Can I include commits from master after the beta was cut?

No. The changelog range always ends at the commit the beta tag points to, never at master HEAD. Commits landing after the beta source ship in the next release and belong only in a what's-next section.

Why should an existing changelog file not be overwritten?

An existing changelog may contain reviewed human edits, so the workflow requires reading it first and asking the reviewer whether to keep, regenerate, or update specific sections. Silent overwrites risk losing approved release content.