agentleFS
Sign inStart free
AdhamxonAdhamxon/claude-code-skills/.claude/skills/release-notes/SKILL.md

release-notes

Skill2 starsChanged 4 months agoMITView on GitHub

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.

176 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 156 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first.

    line 14
  2. Distinctive:

    Gather raw material: Read all provided tickets, changelogs, or descriptions.

    line 18
  3. Distinctive:

    Use plain language — avoid jargon, internal codenames, or ticket numbers

    line 32
  4. Distinctive:

    Keep each entry to 1-3 sentences

    line 33

“Common” is measured: kept by at least 6 in 10 of the 156 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free