Heim

Skill

Dokumentation

release-notes

phuryn/pm-skills

Wandeln Sie technische Tickets, PRDs oder Änderungsprotokolle in ansprechende, benutzerorientierte Versionshinweise um, die nach Kategorien geordnet sind.

...Alle erweitern

Zeit aktualisiert 29. September 2026

# markdown # changelog # linear # jira # release notes # product documentation

Generator für Versionshinweise

Wandeln Sie technische Tickets, PRDs oder interne Änderungsprotokolle in ansprechende, benutzerorientierte Versionshinweise um.

Kontext

Sie verfassen Release-Hinweise für $ARGUMENTS.

Wenn der Nutzer Dateien bereitstellt (JIRA-Exporte, Linear-Tickets, PRDs, Git-Logs oder interne Änderungsprotokolle), lesen Sie diese zunächst durch. Wenn darin eine Produkt-URL erwähnt wird, nutzen Sie die Websuche, um sich über das Produkt und die Zielgruppe zu informieren.

Anleitung

Sammeln Sie das Ausgangsmaterial: Lesen Sie alle bereitgestellten Tickets, Änderungsprotokolle oder Beschreibungen. Extrahieren Sie:
- Was sich geändert hat (Funktion, Verbesserung oder Fehlerbehebung)
- Wen betrifft es (welches Nutzersegment)?
- Warum es wichtig ist (der Nutzen für den Nutzer)
Änderungen kategorisieren:
- Neue Funktionen: Völlig neue Funktionen
- Verbesserungen: Erweiterungen bestehender Funktionen
- Fehlerbehebungen: Behobene Probleme
- Kompatibilitätsänderungen: Alles, was eine Aktion seitens des Nutzers erfordert (Migrationen, API-Änderungen)
- Veraltete Funktionen: Funktionen, die auslaufen
Verfassen Sie jeden Eintrag nach folgenden Grundsätzen:
- Stellen Sie den Nutzen für den Benutzer in den Vordergrund, nicht die technische Änderung
- Verwenden Sie eine einfache Sprache – vermeiden Sie Fachjargon, interne Codenamen oder Ticketnummern
- Beschränken Sie jeden Eintrag auf 1–3 Sätze
- Fügen Sie Grafiken oder Screenshots hinzu, sofern der Nutzer diese bereitstellt
Beispiele für die Umformulierung:
- Technisch: „Redis-Caching-Schicht für Dashboard-API-Endpunkte implementiert“
- Für den Nutzer: „Dashboards werden jetzt bis zu dreimal schneller geladen, sodass Sie weniger Zeit mit Warten und mehr Zeit mit der Analyse verbringen.“
- Technisch: „Race-Condition im parallelen Checkout-Ablauf behoben“
- Für den Nutzer: „Ein Problem wurde behoben, bei dem einige Bestellungen in Zeiten mit hohem Datenverkehr fehlschlagen konnten.“

Aufbau der Versionshinweise:

# [Produktname] — [Version / Datum]

## Neue Funktionen
- **[Funktionsname]**: [1–2 Sätze zur Beschreibung der Funktionsweise und ihrer Bedeutung]

## Verbesserungen
- **[Bereich]**: [Was wurde verbessert und wie hilft es?]

## Fehlerbehebungen
- Behoben: [Beschreibung des Problems in für Nutzer verständlicher Sprache]

## Kompatibilitätsänderungen (falls vorhanden)
- **Erforderliche Maßnahme**: [Was Nutzer tun müssen]

Passen Sie den Ton an den Stil des Produktsan – professionell für B2B, freundlich für Endverbraucher, entwicklerorientiert für APIs.

Als Markdown-Dokument speichern. Wenn der Nutzer HTML oder ein anderes Format wünscht, entsprechend konvertieren.

Auf GitHub ansehen

---
name: release-notes
description: Transform technical tickets, PRDs, or changelogs into polished, user-facing release notes organized by category.
---

## 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.