Release Notes Generator
Erstelle aus einem Sprint voller abgeschlossener Tickets automatisch glänzende, benutzerorientierte Release Notes.
Release Notes aus Roh‑Tickets zu schreiben ist mühsam: interne Arbeit herausfiltern, Entwickler‑Sprache in verständliche Nutzersprache übersetzen, Formatierung einheitlich halten. Dieses Skill erledigt das alles.
Prompt Template
/schedule
### Schritt 1 — Abgeschlossene Tickets sammeln
Durchsuche {{TICKET_SOURCES}} nach Elementen, die in den letzten {{TIME_WINDOW}} auf „erledigt“, „ausgeliefert“, „gemerged“ oder „geschlossen“ gesetzt wurden.
Überspringe: in Arbeit, nur intern, reine Bugfixes ohne sichtbare UX‑Änderung, Chores, Refactoring,
alles mit Label „internal“, „infra“ oder „ops“.
### Schritt 2 — Nach Produktbereich gruppieren
Verwende Ticket‑Labels oder Projektnamen. Fasse Bereiche mit weniger als 2 Elementen in der nächstgelegenen Gruppe zusammen.
### Schritt 3 — Release Notes schreiben
Für jeden Bereich:
**[Bereichstag]**
**[Titel]** — 2–5 Wörter, Präsens, Feature‑Name, kein Commit‑Message-Stil.
Gut: „Schnellere Suchergebnisse“, „Neues Abrechnungsdashboard“. Nie: „hinzugefügt“, „behoben“, „ausgeliefert“.
[Beschreibung] — 1–3 Sätze an den Benutzer. Beginne mit der Änderung und warum sie wichtig ist.
Verwende die Formulierung „Sie können jetzt…“. Keine Aufzählungspunkte. Keine Ticket‑IDs, Sprintnamen oder Entwicklernamen.
### Schritt 4 — Speichern
Datum oben: Monat DD, YYYY. Einträge nach Bereich gruppiert.
Speichern als ReleaseNotes_YYYY-MM-DD.docx in {{OUTPUT_FOLDER}}.
Nicht veröffentlichen – nur zur Prüfung speichern. Wenn keine Tickets gefunden wurden, gib an, welche Quellen überprüft wurden.
Einrichtung
| Feld | Wert |
|---|---|
| Benötigte MCPs | Linear / Jira / GitHub Issues, Google Drive |
| Ausgabe | ReleaseNotes_YYYY-MM-DD.docx → /Product/ReleaseNotes |
| Zeitplan | Manuell vor jedem Release oder wöchentlich |
Platzhalter zum Ausfüllen
{{TICKET_SOURCES}}— z. B.Linear,JiraoderGitHub Issues{{TIME_WINDOW}}— z. B.die letzten 7 Tage,die letzten 2 Wochenoderdieser Sprint{{OUTPUT_FOLDER}}— z. B./Product/ReleaseNotes
Tipps
- Gute Ticket‑Hygiene ergibt bessere Release Notes. Beschreibungen, die mit „Benutzer können jetzt…“ beginnen, liefern die besten Ergebnisse.
- Kombiniere das Skill mit
update-knowledge-base, um zu markieren, welche Hilfsartikel nach jedem Release aktualisiert werden müssen. - Halte API-/Webhook‑Änderungen in einem separaten Label – das Skill gibt ihnen dann einen eigenen technischen Ton.