release-changelog

Generate stable Paperclip release changelogs at releases/vYYYY.MDD.P.md.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It eliminates the manual, error-prone effort of compiling a user-facing changelog for each stable Paperclip release by automatically gathering the right commits, changesets, and merged PR context.

Core Features & Use Cases

  • Stable calver changelog generation: Produces a release artifact at releases/vYYYY.MDD.P.md using Paperclip’s calendar versioning rules rather than semver.
  • User-focused change categorization: Detects and surfaces breaking changes with an Upgrade Guide, while grouping highlights, improvements, and fixes for readability.
  • Contributor attribution support: Adds precise PR links and @GitHub-username attribution when the bullet item maps confidently to a merged PR.

Quick Start

Use this skill to generate the stable Paperclip changelog for the next release window and review the draft for accuracy before publishing.

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 merged pull requests and git tags?

To generate a release changelog, the system collects commits, changesets, and merged pull request context since the last stable git tag, categorizing them into a structured markdown summary with contributor attribution and breaking changes upgrade guides.

How does calver changelog generation work for calendar versioning releases?

Calver changelog generation works by deriving the stable version strictly from the agreed release date and intent, producing a release artifact named with the vYYYY.MDD.P format instead of using semantic versioning increments.

Does the changelog generation process handle breaking changes separately?

Yes, breaking changes are detected and surfaced in a dedicated section with an Upgrade Guide, ensuring user-facing readability by grouping highlights, improvements, and fixes into separate structured categories.

Can I use this to create a canary release changelog?

No, this process specifically excludes canary-specific changelog creation, applying only to stable release preparation workflows where teams need a user-facing summary for a calver-based stable release.

What happens if a release changelog file already exists at the target path?

If a changelog file already exists at the releases/vYYYY.MDD.P.md path, the process ensures idempotency by detecting the existing file and preventing duplicate artifact generation.