AgentAlley
Submit

Release notes skill

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

by phuryn·MIT license·★ 26,557 Stars on the repo·GitHub ↗

Use now

Files of Release notes

phuryn/main1 file shown
SKILL.md
Show the full text64 lines
release-notes/SKILL.md64 lines · 2.5 KB
Outline
RawView on GitHub

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.

1---
2name: release-notes
3description: "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."
4---
5 
6## Release Notes Generator
7 
8Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes.
9 
10### Context
11 
12You are writing release notes for **$ARGUMENTS**.
13 
14If 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.
15 
16### Instructions
17 
181. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract:
19 - What changed (feature, improvement, or fix)
20 - Who it affects (which user segment)
21 - Why it matters (the user benefit)
22 
232. **Categorize changes**:
24 - **New Features**: Entirely new capabilities
25 - **Improvements**: Enhancements to existing features
26 - **Bug Fixes**: Issues resolved
27 - **Breaking Changes**: Anything that requires user action (migrations, API changes)
28 - **Deprecations**: Features being sunset
29 
303. **Write each entry** following these principles:
31 - Lead with the user benefit, not the technical change
32 - Use plain language — avoid jargon, internal codenames, or ticket numbers
33 - Keep each entry to 1-3 sentences
34 - Include visuals or screenshots if the user provides them
35 
36 **Example transformations**:
37 - Technical: "Implemented Redis caching layer for dashboard API endpoints"
38 - User-facing: "Dashboards now load up to 3× faster, so you spend less time waiting and more time analyzing."
39 
40 - Technical: "Fixed race condition in concurrent checkout flow"
41 - User-facing: "Fixed an issue where some orders could fail during high-traffic periods."
42 
434. **Structure the release notes**:
44 
45 ```
46 # [Product Name] — [Version / Date]
47 
48 ## New Features
49 - **[Feature name]**: [1-2 sentence description of what it does and why it matters]
50 
51 ## Improvements
52 - **[Area]**: [What got better and how it helps]
53 
54 ## Bug Fixes
55 - Fixed [issue description in user terms]
56 
57 ## Breaking Changes (if any)
58 - **Action required**: [What users need to do]
59 ```
60 
615. **Adjust tone** to match the product's voice — professional for B2B, friendly for consumer, developer-focused for APIs.
62 
63Save as a markdown document. If the user wants HTML or another format, convert accordingly.
64 

Discussion

Alternatives

CI/CD and AutomationAutomates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.Infrastructure & ops · MITFinishing a development branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the workCoding · MITUsing git worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackCoding · MITClaude Code Skill (Slash Command): review-and-commit.mdA slash command for Claude Code to perform (a) commit(s) following the conventional style.Coding · CC0-1.0

Browse more free Claude skills or everything in Development.