How do I install the Release Notes skill?

Run npx skillmds@latest add peteedoo/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. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. 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?

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

Release Notes by peteedoo — Agent Skill

Name: Release Notes
Rating: 4.2 (5 reviews)
Author: peteedoo

Release Notes

Generate user-facing release notes from tickets, PRDs, or changelogs. Creates clear, engaging summaries organized by category (new features, improvements, fixes). Use when writing release notes, creating changelogs, announcing product updates, or summarizing what shipped.

peteedoo Updated Aug 19, 2026 0 repo stars

File contents

Release Notes Generator

Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes.

Context

You are writing release notes for $ARGUMENTS.

If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience.

Instructions

Gather raw material: Read all provided tickets, changelogs, or descriptions. Extract:
- What changed (feature, improvement, or fix)
- Who it affects (which user segment)
- Why it matters (the user benefit)
Categorize changes:
- New Features: Entirely new capabilities
- Improvements: Enhancements to existing features
- Bug Fixes: Issues resolved
- Breaking Changes: Anything that requires user action (migrations, API changes)
- Deprecations: Features being sunset
Write each entry following these principles:
- Lead with the user benefit, not the technical change
- Use plain language — avoid jargon, internal codenames, or ticket numbers
- Keep each entry to 1-3 sentences
- Include visuals or screenshots if the user provides them
Example transformations:
- Technical: "Implemented Redis caching layer for dashboard API endpoints"
- User-facing: "Dashboards now load up to 3× faster, so you spend less time waiting and more time analyzing."
- Technical: "Fixed race condition in concurrent checkout flow"
- User-facing: "Fixed an issue where some orders could fail during high-traffic periods."

Structure the release notes:

# [Product Name] — [Version / Date]

## New Features
- **[Feature name]**: [1-2 sentence description of what it does and why it matters]

## Improvements
- **[Area]**: [What got better and how it helps]

## Bug Fixes
- Fixed [issue description in user terms]

## Breaking Changes (if any)
- **Action required**: [What users need to do]

Adjust tone to match the product's voice — professional for B2B, friendly for consumer, developer-focused for APIs.

Save as a markdown document. If the user wants HTML or another format, convert accordingly.

---name: release-notesdescription: Generate user-facing release notes from tickets, PRDs, or changelogs. Creates clear, engaging summaries organized by category (new features, improvements, fixes). Use when writing release notes, creating changelogs, announcing product updates, or summarizing what shipped.---## Release Notes GeneratorTransform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes.### ContextYou are writing release notes for **$ARGUMENTS**.If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience.### Instructions1. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract: - What changed (feature, improvement, or fix) - Who it affects (which user segment) - Why it matters (the user benefit)2. **Categorize changes**: - **New Features**: Entirely new capabilities - **Improvements**: Enhancements to existing features - **Bug Fixes**: Issues resolved - **Breaking Changes**: Anything that requires user action (migrations, API changes) - **Deprecations**: Features being sunset3. **Write each entry** following these principles: - Lead with the user benefit, not the technical change - Use plain language — avoid jargon, internal codenames, or ticket numbers - Keep each entry to 1-3 sentences - Include visuals or screenshots if the user provides them **Example transformations**: - Technical: "Implemented Redis caching layer for dashboard API endpoints" - User-facing: "Dashboards now load up to 3× faster, so you spend less time waiting and more time analyzing." - Technical: "Fixed race condition in concurrent checkout flow" - User-facing: "Fixed an issue where some orders could fail during high-traffic periods."4. **Structure the release notes**: ``` # [Product Name] — [Version / Date] ## New Features - **[Feature name]**: [1-2 sentence description of what it does and why it matters] ## Improvements - **[Area]**: [What got better and how it helps] ## Bug Fixes - Fixed [issue description in user terms] ## Breaking Changes (if any) - **Action required**: [What users need to do] ```5. **Adjust tone** to match the product's voice — professional for B2B, friendly for consumer, developer-focused for APIs.Save as a markdown document. If the user wants HTML or another format, convert accordingly.

Frequently asked questions