Skip to main content
NEW · APP STORE Now on iOS · macOS · iPad Android & Windows soon GET IT
Prompts Release Notes from Tickets and Changelogs

agent writing skill risk: low

Release Notes from Tickets and Changelogs

Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes. Categorize changes into new features, improvements, bug fixes, breaking changes,…

SKILL 1 file

SKILL.md
---
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.

INPUTS

$ARGUMENTS REQUIRED

product name and version/date for the title

e.g. Acme Dashboard v2.4

REQUIRED CONTEXT

  • tickets
  • PRDs
  • changelogs
  • product descriptions

OPTIONAL CONTEXT

  • product URL
  • visuals or screenshots
  • product voice/tone

TOOLS REQUIRED

  • web_search
  • file_search

ROLES & RULES

Role assignments

  • You are writing release notes for **$ARGUMENTS**.
  1. Read all provided tickets, changelogs, or descriptions.
  2. Extract what changed, who it affects, and why it matters.
  3. Categorize changes into New Features, Improvements, Bug Fixes, Breaking Changes, and Deprecations.
  4. Lead with the user benefit, not the technical change.
  5. Use plain language — avoid jargon, internal codenames, or ticket numbers.
  6. Keep each entry to 1-3 sentences.
  7. Include visuals or screenshots if the user provides them.
  8. Adjust tone to match the product's voice.
  9. Save as a markdown document.

EXPECTED OUTPUT

Format
markdown
Schema
markdown_sections · New Features, Improvements, Bug Fixes, Breaking Changes
Constraints
  • use specified section headings and bullet format
  • lead each entry with user benefit in plain language
  • keep entries to 1-3 sentences
  • omit ticket numbers and jargon

SUCCESS CRITERIA

  • Transform technical tickets, PRDs, or changelogs into polished user-facing release notes.
  • Organize by category with clear user benefit focus.
  • Follow the exact markdown structure provided.

FAILURE MODES

  • May retain technical jargon if extraction step is skipped.
  • May produce incomplete sections if input material lacks detail.

EXAMPLES

Includes two example transformations from technical descriptions to user-facing release note text.

CAVEATS

Dependencies
  • Requires provided tickets, changelogs, PRDs, or product URL.
Missing context
  • Explicit product name or version when $ARGUMENTS is empty or minimal
  • Preferred output length or number of bullet items per section
Ambiguities
  • Does not specify how the model should access or read provided files (JIRA exports, etc.).
  • Does not define what 'product voice' examples or guidelines to follow when tone adjustment is needed.

QUALITY

OVERALL
0.82
CLARITY
0.90
SPECIFICITY
0.80
REUSABILITY
0.85
COMPLETENESS
0.80

IMPROVEMENT SUGGESTIONS

  • Add a placeholder for product name and version at the top of the Context section so the template works without extra user input.
  • Specify allowed input formats (e.g., markdown, JSON, CSV) and any length limits for the generated notes.

USAGE

Copy the prompt above and paste it into your AI of choice — Claude, ChatGPT, Gemini, or anywhere else you're working. Replace any placeholder sections with your own context, then ask for the output.

MORE FOR AGENT