Agent skill · writing content · backnotprop
release-plannotator
Prepare and execute a Plannotator release — draft release notes with full contributor credit, bump versions across all package files, build in dependency order, and kick off the tag-driven release pipeline. Use this skill whenever the user mentions preparing a release, bumping versions, writing release notes, tagging a release, or publishing. Also trigger when the user says things like "let's ship", "prep a release", "what's changed since last release", or "time to cut a new version".
Why this skill is useful
Adds a detailed multi-step workflow for preparing and executing a release, including scripts for gathering contributor data and drafting release notes.
What it needs
Requires github account access. About 10k tokens when loaded. Last updated 2026-08-07. 7,561 stars on the source repository.
What this skill does
Plannotator Release The process has four phases. Phase 1 (release notes) is where most of the work happens — present the draft for review before proceeding to later phases. Phase 1: Draft Release Notes This is the most important phase. The release notes are the public face of each version and the primary way the community sees their contributions recognized. Step 1: Determine scope 1. Find the latest release tag: git tag --sort=-v:refname head -1 2. Determine the new version number. Ask the user if unclear (patch, minor, or major). 3. Gather all changes since the last tag: git log --oneline <last-tag>..HEAD for commit history git log --merges --oneline <last-tag>..HEAD for merged PRs 4. For each PR, use gh pr view <number> --json title,author,body,closedIssues,labels to get details. Step 2: Research contributors This is critical. Every person who participated in the release gets credit — not just PR authors. For each PR and linked issue, collect: PR authors — the person who wrote the code Issue reporters — who filed the bug or feature request Issue commenters — who participated in the discussion with useful context Discussion creators — who started relevant GitHub Discussions Feature requestors — check the linked "closes #N" issues and their authors Use the GitHub API via gh: Step 3: Write the release notes Read the reference release notes in references/ for the canonical template structure. These are real release notes from previous versions — match their tone, structure, and level of detail. release-notes-v0.13.0.md — large release, 14 PRs, 3 first-time contributors, "New Contributors" + narrative "Contributors" section release-notes-v0.12.0.md — large community release, 14 PRs, 10 external, detailed narrative "Contributors" section release-notes-v0.13.1.md — small patch release, 2 PRs, no external authors, "Community" section focused on issue reporters Pay attention to how each reference handles contributor crediting differently. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills backnotprop/release