mcpField
R
release-notes

release-notes

github.com/phurynDevelopment27.5k3.0k installsUpdated 2w ago
Repository

About release-notes

A release-notes writing skill for product and development teams. It turns tickets, PRDs, and changelogs into concise, user-facing notes organized by change type and tailored to the product's audience and tone.

Key features

  1. 01Extracts changes and user benefits
  2. 02Categorizes features, improvements, and fixes
  3. 03Identifies breaking changes and deprecations
  4. 04Writes concise, user-facing entries
  5. 05Structures notes in Markdown

Use cases

  1. 01Converting tickets into release notes
  2. 02Summarizing an internal changelog for users
  3. 03Explaining breaking changes in plain language

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/phuryn/pm-skills --skill release-notes

After installing, type/release-notesin Claude Code to confirm it loaded.

Details

From the project 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.

Comments

Markdown supported