PluginBench
Skill
Review
Audit score 70

release-notes

phuryn/pm-skills

Generate polished, user-facing release notes from tickets, PRDs, and changelogs.

What is release-notes?

Transforms technical tickets, PRDs, or internal changelogs into clear, engaging release notes organized by category (new features, improvements, fixes, breaking changes, deprecations). Use when writing release notes, creating changelogs, announcing product updates, or summarizing what shipped.

  • Extracts what changed, who it affects, and why it matters from raw technical material
  • Categorizes changes into New Features, Improvements, Bug Fixes, Breaking Changes, and Deprecations
  • Translates technical jargon into user-benefit language with concrete examples
  • Structures release notes in markdown with consistent formatting and tone
  • Adjusts voice to match product audience (B2B professional, consumer-friendly, developer-focused)

How to install release-notes

npx skills add https://github.com/phuryn/pm-skills --skill release-notes
Claude Code
Cursor
Windsurf
Cline

How to use release-notes

  1. 1.Provide raw material: JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs
  2. 2.Optionally provide product URL for web search context or visual assets (screenshots)
  3. 3.Specify the product name, version, and release date
  4. 4.Let the skill extract changes, categorize them, and generate structured release notes
  5. 5.Review and adjust tone or format as needed (markdown, HTML, etc.)

Use cases

Good for
  • Writing release notes for a software product launch or quarterly update
  • Converting JIRA or Linear ticket exports into customer-facing changelogs
  • Summarizing Git logs or internal PRDs into structured release announcements
  • Creating breaking-change notices for API or platform updates
  • Generating deprecation notices for sunsetting features
Who it's for
  • Product managers writing release announcements
  • Engineering teams documenting shipped work for customers
  • Marketing teams creating product update communications
  • API maintainers announcing version changes
  • Anyone translating technical changes into user-friendly language

release-notes FAQ

What formats can I provide as input?

JIRA exports, Linear tickets, PRDs, Git logs, internal changelogs, or plain text descriptions. You can also provide a product URL for context.

How does it decide what's a feature vs. an improvement?

New Features are entirely new capabilities. Improvements are enhancements to existing features. The skill extracts this from your source material and applies consistent categorization.

Can I customize the tone or structure?

Yes. Specify your product's voice (professional B2B, friendly consumer, developer-focused) and desired format (markdown, HTML, etc.) and the skill will adjust accordingly.

What if I have breaking changes or deprecations?

The skill includes dedicated sections for Breaking Changes and Deprecations. Include these in your source material and they'll be highlighted with action-required language.

Does it remove internal jargon and ticket numbers?

Yes. It translates technical language into plain user-benefit language and omits internal codenames and ticket references by default.

Full instructions (SKILL.md)

Source of truth, from phuryn/pm-skills.


name: release-notes description: "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 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.