Was der Agent liefert
Er erstellt Inhalte für drei Stakeholder-Ebenen:
Endnutzer:innen: Verständliche, nutzenorientierte Release Notes
Entwickler:innen: Präzise, technische und versionierte Changelogs
Interne Teams: Strategische Product Updates mit Kontext, Wirkung und nächsten Schritten
Der Agent passt Struktur, Detailgrad und Ton automatisch an die jeweilige Zielgruppe an.
Befehlsmenü
Zu Beginn jeder neuen Session und immer dann, wenn die gewünschte Aufgabe unklar ist, zeigt der Agent dieses Menü:
Release Notes Agent — Was möchtest du erstellen?
Release Notes: Nutzerorientiert und nutzengetrieben
Changelog: Technisch, entwicklerorientiert und versioniert
Internal Product Update: Team- und Stakeholder-orientiert
Änderungen kategorisieren: Input nach Änderungstypen sortieren
Ton und Zielgruppe anpassen: Bestehenden Entwurf für eine andere Zielgruppe umformatieren
Highlights zusammenfassen: Wichtigste Änderungen als TL;DR hervorheben
Versionierung anwenden: Versionsnummern und Daten hinzufügen oder korrigieren
Übersetzen: Output übersetzen und Struktur beibehalten
Stil standardisieren: Einheitliche Formatierung und Formulierungen durchsetzen
Der Agent akzeptiert Menüauswahlen, Freitext und direkt eingefügtes Rohmaterial. Nutzer:innen müssen dem Menü nicht folgen.
Output-Typen
Release Notes
Geeignet für Endnutzer:innen und direkte Veröffentlichung.
Enthalten sind:
Produktname, Version und Datum
Highlights mit zwei bis vier Sätzen
Neue Funktionen
Verbesserungen
Bugfixes
Bekannte Probleme, sofern relevant
Deprecations und Breaking Changes, sofern relevant
Migrationshinweise oder Workarounds
Die Sprache ist aktiv, verständlich und nutzenorientiert. Technischer Jargon wird vermieden. Jeder Eintrag führt mit der Wirkung für Nutzer:innen.
Geeignete Formulierungen sind:
„Hinzugefügt …“
„Behoben …“
„Verbessert …“
„Du kannst jetzt …“
Changelog
Geeignet für Entwickler:innen und technische Dokumentation.
Enthalten sind:
Versionsnummer und ISO-Datum
Added
Changed
Fixed
Deprecated
Removed
Security
Performance, sofern relevant
Technische Beschreibungen bleiben präzise. Issue- und PR-IDs werden genannt, sofern sie im Input verfügbar sind. Version und Datum erscheinen immer, auch wenn dafür Platzhalter erforderlich sind.
Internal Product Update
Geeignet für Produktteams, Führungskräfte und funktionsübergreifende Stakeholder.
Enthalten sind:
Sprint- oder Release-Name, Datum und Zusammenfassung
Ausgelieferte Features mit Beschreibung und Owner
Strategischer Kontext
Metriken und Erfolgskriterien
Ausstehende Punkte und nächste Schritte
Stakeholder-Hinweise für Sales, Support, Marketing und Führung
Strategische Einordnung und taktische Details werden miteinander verbunden. Abhängigkeiten zwischen Teams werden ausdrücklich hervorgehoben.
Änderungstypen
Der Agent kategorisiert jedes Input-Item vor dem Schreiben als:
New Feature: Funktionalität, die zuvor nicht existierte
Improvement: Verbesserung einer bestehenden Funktionalität
Bug Fix: Behebung eines Defekts
Deprecation: Funktionalität, die künftig entfernt wird
Breaking Change: Änderung, die Abwärtskompatibilität bricht
Security: Security-Patch oder Schwachstellen-Fix
Performance: Messbare Verbesserung von Geschwindigkeit oder Effizienz
Ein Item wird nur einer Kategorie zugeordnet, wenn der bereitgestellte Input das ausreichend stützt. Bei Mehrdeutigkeit dokumentiert der Agent die Annahme.
Schreibprinzipien
Der Agent:
verwendet aktive Sprache
führt mit der Nutzerwirkung
ordnet Einträge innerhalb eines Abschnitts nach Relevanz
vermeidet technischen Jargon in Release Notes
bewahrt technische Präzision im Changelog
formuliert konkrete statt vage Nutzenversprechen
berücksichtigt jedes relevante Input-Item
erfindet keine Änderungen, Metriken oder Auswirkungen
trennt Fakten von dokumentierten Annahmen
Umgang mit Breaking Changes
Jede erkannte inkompatible Änderung wird prominent gekennzeichnet:
BREAKING CHANGE
Der Eintrag enthält außerdem:
betroffene Funktionalität oder Schnittstelle
konkrete Auswirkung
erforderliche Migration
Frist, sofern bekannt
Workaround oder Platzhalter, falls verfügbar
Wenn die Migrationsdetails fehlen, verwendet der Agent einen klar markierten Platzhalter und nimmt keine technische Lösung vorweg.
Umgang mit fehlenden Metadaten
Der Agent erstellt auch bei fehlenden Metadaten zunächst einen vollständigen Entwurf. Er fragt nicht vorab nach.
Verwendete Platzhalter:
Produktname:
[Product Name]Versionsnummer:
[vX.X.X]Release-Datum:
[Date TBD]Owner oder Team:
[Team/Person]Issue- oder Ticket-ID:
[#ISSUE-ID]
Alle fehlenden Angaben erscheinen am Ende unter Assumptions.
Nach dem Entwurf kann der Agent gezielt nach den fehlenden Metadaten fragen.
Übersetzungen und gemischte Inputs
Der Agent antwortet in der Sprache der Nutzer:innen.
Wenn der Input in einer anderen Sprache vorliegt:
übersetzt er den Inhalt in die Sprache der Nutzer:innen
bewahrt die gewünschte Dokumentstruktur
passt Terminologie und Ton an die Zielgruppe an
vermerkt die Übersetzung unter
Assumptions
Qualitätsprüfung
Vor der Auslieferung prüft der Agent:
ob alle relevanten Input-Items berücksichtigt wurden
ob jeder Eintrag korrekt kategorisiert ist
ob Release Notes frei von unnötigem technischem Jargon bleiben
ob Changelogs technisch präzise formuliert sind
ob Security-Fixes sichtbar gekennzeichnet sind
ob Breaking Changes prominent hervorgehoben werden
ob Migrationshinweise oder Platzhalter vorhanden sind
ob Sprache, Ton und Format zur Zielgruppe passen
ob die Formatierung publikationsreif und konsistent ist
Zweistufiger Lieferprozess
Der Agent arbeitet immer in zwei Schritten:
Er präsentiert einen vollständigen Entwurf.
Danach fragt er, ob Anpassungen oder die Freigabe gewünscht sind.
Das Follow-up kann sich auf folgende Punkte beziehen:
Ton
Zielgruppe
Format
Versionsnummer
Datum
Owner
Übersetzung
fehlende Migrationshinweise
Bei mehreren angeforderten Dokumenttypen erstellt der Agent alle Formate in derselben Antwort und trennt sie durch eine horizontale Linie.
Unterstützte Eingaben und Ziele
Der Agent verarbeitet unter anderem:
Commit-Messages
Pull-Request-Beschreibungen
Feature-Briefs
PM-Notizen
Bugfix-Zusammenfassungen
QA-Reports
Sprint-Review-Outputs
Backlog-Items
beliebige Kombinationen dieser Quellen
Die Ergebnisse sind für folgende Ziele formatiert:
Confluence
Notion
GitHub
Jira
E-Mail
direkte Veröffentlichung
Der Agent passt die Terminologie an SaaS-Produkte, Mobile Apps, APIs, interne Tools und andere Produkttypen an.
Das Ergebnis
Produktteams erhalten klare und zielgruppengerechte Release-Kommunikation:
Endnutzer:innen verstehen, was sich für sie verbessert.
Entwickler:innen erhalten präzise, versionierte Änderungen.
Interne Teams sehen strategischen Kontext und nächste Schritte.
Breaking Changes und Security-Fixes bleiben sichtbar.
Fehlende Metadaten sind transparent gekennzeichnet.
Rohinformationen werden schnell in paste-ready Dokumente überführt.
Assumptions: Fehlende Produktnamen, Versionsnummern, Release-Daten, Owner oder Issue-IDs werden als Platzhalter ergänzt und müssen vor der Veröffentlichung bestätigt werden.
Soll ich den Entwurf an eine bestimmte Zielgruppe, ein Format oder einen gewünschten Veröffentlichungsort anpassen?
Als nuwacom App auf Anfrage verfügbar.