release

Generate changelogs, release notes, and version tags following repository conventions.

2|Updated May 14, 2026
One-click install
npx skills add https://github.com/AnthonyPoschen/agent-skills --skill release-anthonyposchen
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: release
Source: https://github.com/AnthonyPoschen/agent-skills/tree/main/skills/release
Command: npx skills add https://github.com/AnthonyPoschen/agent-skills --skill release-anthonyposchen

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Preparing a release involves tedious, error-prone work: picking the right version, summarizing changes since the last tag, updating changelogs, and tagging safely. This Skill standardizes that entire workflow so releases are consistent, user-facing, and never published from a dirty worktree. ## Core Features & Use Cases - Release Records: Create, update, review, or correct changelogs, GitHub Release drafts, and release summaries without tagging or publishing unless asked. - Version Selection: Follow the repository's existing versioning convention (SemVer or otherwise), falling back to SemVer-compatible CalVer (vYYYY.M.D) or Go-module-safe v0.YYYYMMDD.N when no convention exists. - Safe Tag & Publish: Require a clean worktree, commit changelog updates before tagging, create annotated tags, and push only with explicit authority. - Use Case: Ask for release notes since the last tag and receive grouped, user-facing notes (Breaking, Added, Fixed, Security) ready to paste into a GitHub Release, plus the exact commit ready to tag. ## Quick Start Prepare release notes for all changes since the previous tag and tell me which commit is ready to tag.

Frequently Asked Questions about release

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

FAQPage Schema
How do I generate release notes from Git commits?▼

Compare the previous release tag to HEAD using git log and git diff, then group changes by user impact under headings like Breaking, Added, Fixed, and Security. Write entries in plain language and exclude internal-only commits that do not affect users.

How do I choose a version number for a release?▼

Follow the repository's existing convention from tags, package manifests, and release automation first. If no convention exists, use SemVer-compatible CalVer like v2026.5.20, or v0.YYYYMMDD.N for Go modules to avoid +incompatible resolution.

Does CalVer work with Go modules?▼

Standard date-based tags like v2026.5.20 break Go modules because majors above v1 require a module path suffix. Use the Go-safe format v0.YYYYMMDD.N with the patch component for same-day release ordering.

Why should the worktree be clean before tagging a release?▼

A clean worktree guarantees the tag points at a fully committed, reproducible state. If git status --short prints anything, stop and commit, discard, or explicitly ignore those changes before generating release notes or tagging.

When should I update CHANGELOG.md versus docs/releases files?▼

Follow the existing repository convention. A common model keeps CHANGELOG.md as a concise index linking to per-tag files in docs/releases/, while the GitHub Release holds the polished public notes. Do not duplicate full notes in multiple places.