Agent skill · writing content · paperclipai
release-changelog
Generate the stable Paperclip release changelog at releases/vYYYY.MDD.P.md by reading commits, changesets, and merged PR context since the last stable tag.
Why this skill is useful
Adds specific commands and workflows for generating a changelog that the AI wouldn't reliably generate on its own.
What it needs
About 7k tokens when loaded. Last updated 2026-08-07. 75,771 stars on the source repository.
What this skill does
Release Changelog Skill Generate the user-facing changelog for the stable Paperclip release. Versioning Model Paperclip uses calendar versioning (calver): Stable releases: YYYY.MDD.P (e.g. 2026.318.0) Canary releases: YYYY.MDD.P-canary.N (e.g. 2026.318.1-canary.0) Git tags: vYYYY.MDD.P for stable, canary/vYYYY.MDD.P-canary.N for canary There are no major/minor/patch bumps. The stable version is derived from the intended release date (UTC) plus the next same-day stable patch slot. Output: releases/vYYYY.MDD.P.md a release Case, upserted by (caseType, key) when Cases are enabled, with a body document revision containing the changelog body Important rules: even if there are canary releases such as 2026.318.1-canary.0, the changelog file stays releases/v2026.318.1.md do not derive versions from semver bump types do not create canary changelog files Channel Process — Source Commit and File Location Stables promote a soaked beta, so the changelog describes the beta's source commit, not the tip of master: The release source is the commit the newest beta/v<beta-version> tag points at ({beta-src} below). Resolve it with: Commits on master after {beta-src} ship in the next release. Never include them; they are input for a "what's next" section, not the changelog. During the soak, the file lives at releases/beta/v{beta-version}.md on the branch release-notes/v{beta-version} (PR to master). The release workflow pushes that branch with a generated skeleton when the beta publishes; work on it and rewrite the skeleton in place. If the branch does not exist (a beta cut before the automation), create it from origin/master and seed the skeleton: The PR must merge to master before the stable is dispatched: the stable preflight reads the file from master and fails without it. Never create releases/vYYYY.MDD.P.md yourself on this path — after the stable ships, the workflow opens a canonicalization PR that renames the beta-keyed file to it. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills paperclipai/release-changelog