---
name: Release Notes
slug: release-notes
category: Writing
description: Release Notes turns tickets, PRDs, or changelogs into polished, user-facing release summaries organized by category. Use when writing release notes, creating changelogs, announcing product updates, or summarizing what shipped.
github: "https://github.com/phuryn/pm-skills/tree/main/pm-execution/skills/release-notes"
stars: 25249
forks: 2707
install: "npx degit https://github.com/phuryn/pm-skills/tree/main/pm-execution/skills/release-notes ~/.claude/skills/release-notes"
installs_to: ~/.claude/skills/release-notes
source_path: pm-execution/skills/release-notes/SKILL.md
collection_size: 25
category_size: 1012
collection_url: "https://dirskills.com/collections/phuryn/pm-skills"
added: 2026-08-14T07:12:15.880Z
last_synced: 2026-08-14T07:12:15.880Z
canonical_url: "https://dirskills.com/skills/release-notes"
---

# Release Notes

Release Notes turns tickets, PRDs, or changelogs into polished, user-facing release summaries organized by category. Use when writing release notes, creating changelogs, announcing product updates, or summarizing what shipped.

**Install:**

```bash
npx degit https://github.com/phuryn/pm-skills/tree/main/pm-execution/skills/release-notes ~/.claude/skills/release-notes
```

## README

## 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

1. **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 sunset

3. **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.