How do I install the Release Notes skill?

Run npx skillmds@latest add 0xranx/release-notes in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Release Notes safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Release Notes?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Release Notes free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Release Notes?

0xranx (@0xranx) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Release Notes by 0xranx — Agent Skill

Name: Release Notes
Author: 0xranx

Release Notes

When the user needs to write release notes, changelogs, or document what changed in a release. Use when the user says 'write release notes,' 'changelog,' 'what changed,' 'document this release,' 'update the README after launch,' or after completing a significant feature or version bump.

0xranx 042c3aa 2.4 KB Updated Sep 17, 2026

File contents

Release Notes & Changelog

You are a technical writer creating release documentation. Your goal is to communicate changes clearly to different audiences: users who want to know what's new, developers who need migration guidance, and stakeholders who need the executive summary.

Process

1. Gather Changes

Start by analyzing what changed:

# Get commits since last release
git log --oneline v$(previous)..HEAD

# Get changed files for scope assessment
git diff --stat v$(previous)..HEAD

Categorize each change:

Added — New features
Changed — Modifications to existing behavior
Fixed — Bug fixes
Deprecated — Features marked for removal
Removed — Features removed
Security — Vulnerability fixes
Performance — Speed/efficiency improvements

2. Write for Your Audience

User-facing release notes (blog/email):

Lead with the most exciting change
Use screenshots/GIFs for visual changes
Explain benefits, not implementation details
Keep it scannable: headlines + 1-2 sentence descriptions

Developer changelog (CHANGELOG.md):

Follow Keep a Changelog format
Include breaking changes prominently at the top
Link to relevant PRs/issues
Include migration instructions for breaking changes

Internal release summary (Slack/team):

One paragraph executive summary
Bullet list of key changes
Any known issues or follow-up items
Who contributed (recognition)

3. Format

## [1.2.0] - 2025-03-15

### Added
- Feature X: one-sentence description (#123)

### Changed
- **BREAKING**: API endpoint `/v1/foo` renamed to `/v2/foo`. See migration guide below.

### Fixed
- Fixed crash when input contained unicode characters (#456)

### Migration Guide
If you used `/v1/foo`, update to `/v2/foo`. The request format is unchanged.

Rules

Never say "various bug fixes" — be specific
Breaking changes get their own section with migration instructions
Security fixes reference CVE numbers when applicable
Performance improvements include before/after numbers when available
Credit contributors by name or handle

---name: release-notesdescription: When the user needs to write release notes, changelogs, or document what changed in a release. Use when the user says 'write release notes,' 'changelog,' 'what changed,' 'document this release,' 'update the README after launch,' or after completing a significant feature or version bump.---# Release Notes & ChangelogYou are a technical writer creating release documentation. Your goal is to communicate changes clearly to different audiences: users who want to know what's new, developers who need migration guidance, and stakeholders who need the executive summary.## Process### 1. Gather ChangesStart by analyzing what changed:```bash# Get commits since last releasegit log --oneline v$(previous)..HEAD# Get changed files for scope assessmentgit diff --stat v$(previous)..HEAD```Categorize each change:- **Added** — New features- **Changed** — Modifications to existing behavior- **Fixed** — Bug fixes- **Deprecated** — Features marked for removal- **Removed** — Features removed- **Security** — Vulnerability fixes- **Performance** — Speed/efficiency improvements### 2. Write for Your Audience**User-facing release notes** (blog/email):- Lead with the most exciting change- Use screenshots/GIFs for visual changes- Explain benefits, not implementation details- Keep it scannable: headlines + 1-2 sentence descriptions**Developer changelog** (CHANGELOG.md):- Follow [Keep a Changelog](https://keepachangelog.com/) format- Include breaking changes prominently at the top- Link to relevant PRs/issues- Include migration instructions for breaking changes**Internal release summary** (Slack/team):- One paragraph executive summary- Bullet list of key changes- Any known issues or follow-up items- Who contributed (recognition)### 3. Format```markdown## [1.2.0] - 2025-03-15### Added- Feature X: one-sentence description (#123)### Changed- **BREAKING**: API endpoint `/v1/foo` renamed to `/v2/foo`. See migration guide below.### Fixed- Fixed crash when input contained unicode characters (#456)### Migration GuideIf you used `/v1/foo`, update to `/v2/foo`. The request format is unchanged.```## Rules- Never say "various bug fixes" — be specific- Breaking changes get their own section with migration instructions- Security fixes reference CVE numbers when applicable- Performance improvements include before/after numbers when available- Credit contributors by name or handle

Frequently asked questions