Newsletter Writer

Was macht Newsletter Writer?

Schreiben Sie Produktupdate-E-Mails und Feature-Announcement-Newsletter. Behandelt Betreffzeilen, Vorschautexte, E-Mail-Struktur und zielgruppengerechte Inhalte.

Eingabeauflösung

Lösen Sie das Argument (falls angegeben) in dieser Reihenfolge auf:

1. Pfad zu einem vorhandenen Marketing-Briefing (.md mit „Executive Summary“ oder „Key Messages“) -> Marketing-Briefing
2. Pfad zu einem vorhandenen Blogbeitrag (.md mit Blogbeitragsstruktur) -> Blogbeitrag
3. Pfad zu einem vorhandenen Changelog (.md mit Abschnitten „Added/Fixed/Changed“ oder CHANGELOG.md) -> Changelog
4. Entspricht GitHub-URL oder #\d+-Muster -> PR
5. Enthält ... oder .. -> Git-Referenzbereich
6. Wird zu vorhandener Datei/Verzeichnis aufgelöst -> Codebase-Feature
7. Andernfalls -> Freitext

Wenn kein Argument angegeben ist, fragen Sie: „Was soll der Newsletter behandeln? Sie können ein Marketing-Briefing, einen Blogbeitrag, ein Changelog, eine PR-URL/-Nummer, einen Git-Referenzbereich, einen Datei-/Verzeichnispfad angeben oder die Aktualisierung einfach beschreiben.“

Wenn mehrere Interpretationen übereinstimmen, bestätigen Sie mit dem Benutzer.

Ablauf

digraph newsletter {
    rankdir=TB;
    "Eingabe auflösen" [shape=box];
    "Phase 1: Entdeckung" [shape=box];
    "Phase 2: Konfiguration" [shape=box];
    "Phase 3: Schreiben" [shape=box];
    "Phase 4: Überprüfung" [shape=box];
    "Genehmigt?" [shape=diamond];
    "Phase 5: Ausgabe" [shape=box];

    "Eingabe auflösen" -> "Phase 1: Entdeckung";
    "Phase 1: Entdeckung" -> "Phase 2: Konfiguration";
    "Phase 2: Konfiguration" -> "Phase 3: Schreiben";
    "Phase 3: Schreiben" -> "Phase 4: Überprüfung";
    "Phase 4: Überprüfung" -> "Genehmigt?";
    "Genehmigt?" -> "Phase 3: Schreiben" [label="Überarbeitungen"];
    "Genehmigt?" -> "Phase 5: Ausgabe" [label="Ja"];
}

Überspringen Sie keine Phasen. Stellen Sie Fragen in einem natürlichen Tempo. Wenn der Benutzer mehrere Fragen auf einmal beantwortet, akzeptieren Sie gebündelte Antworten und springen Sie vor.

Wenn der Benutzer sagt „Nimm einfach die Standardeinstellungen“, „Du entscheidest“ oder Ähnliches, wählen Sie vernünftige Standardwerte basierend auf dem Kontext aus, teilen Sie mit, was Sie gewählt haben, und bitten Sie um eine einzige Bestätigung, bevor Sie fortfahren.

Gehen Sie niemals von etwas aus, ohne es zu bestätigen.

Phase 1: Entdeckung

Schritt 1 – Analysieren Sie die Eingabe

Eingabetyp	Was lesen
Marketing-Briefing	Extrahieren Sie Problemstellung, Wertversprechen, Zielgruppe, Kernbotschaften. Springen Sie zu Schritt 3. Führen Sie Schritt 2 trotzdem durch, wenn dem Briefing der Produktkontext fehlt.
Blogbeitrag	Extrahieren Sie Überschrift, Kernpunkte, Zielgruppe, CTA. Springen Sie zu Schritt 3. Führen Sie Schritt 2 trotzdem durch, wenn der Produktkontext fehlt.
Changelog	Extrahieren Sie alle Einträge. Verwenden Sie dies als Grundlage für eine Zusammenfassungs-E-Mail. Springen Sie zu Schritt 3.
PR	Diff, PR-Beschreibung, Review-Kommentare, Commit-Nachrichten (gh pr view, gh pr diff). Konzentrieren Sie sich bei großen PRs (20+ Dateien) auf benutzerseitige Änderungen.
Git-Referenzen	git diff und git log zwischen Referenzen. Priorisieren Sie bei großen Bereichen Commit-Nachrichten und benutzerseitige Änderungen.
Codebase-Feature	Lesen Sie die angegebenen Dateien/Verzeichnisse.
Freitext	Analysieren Sie die Beschreibung des Benutzers. Wenn es an Details mangelt, bitten Sie den Benutzer um weitere Details oder verweisen Sie auf eine bestimmte Datei/PR. Fallen Sie nur dann auf offene Fragen zurück, wenn der Benutzer nicht anders kann.

Benutzerseitige Änderungen umfassen: neue Funktionen, UI-Änderungen, API-Änderungen, Leistungsverbesserungen, Fehlerbehebungen und Dokumentationsaktualisierungen. Interne Änderungen umfassen: Refactorings, Test-Ergänzungen, CI-Änderungen und Abhängigkeits-Upgrades. Wenn unsicher, listen Sie auf, was Sie gefunden haben, und fragen Sie den Benutzer, welche relevant sind.

Fehlerbehandlung:

• gh nicht verfügbar -> Benutzer informieren, gh auth login vorschlagen, alternative Eingabe anbieten
• Ungültige PR/Referenz -> Benutzer bitten, zu überprüfen
• Datei nicht gefunden -> Nach korrektem Pfad fragen

Schritt 2 – Lesen Sie den breiteren Produktkontext

Lesen Sie, falls vorhanden: README, docs/, package.json (oder Äquivalent).

Wenn nichts gefunden wird, fragen Sie: „Ich konnte keinen Produktkontext im Repository finden. Können Sie kurz das Produkt und seine Zielgruppe beschreiben?“

Schritt 3 – Präsentieren Sie das Verständnis und bestimmen Sie das Format

Präsentieren Sie eine strukturierte Zusammenfassung:

„Hier ist, worauf ich den Newsletter basieren werde:“

• Update A – kurze Beschreibung
• Update B – kurze Beschreibung

„Soll etwas hinzugefügt, entfernt oder korrigiert werden?“

Bestimmen Sie dann das E-Mail-Format basierend auf der Anzahl der Updates:

• Einzelnes größeres Update -> Einzelfeature-E-Mail (fokussiert, tiefgehend)
• Mehrere Updates -> Zusammenfassungs-E-Mail (priorisierte Liste, das Wichtigste ausführlicher)

Bestätigen Sie das Format mit dem Benutzer.

Wenn keine benutzerseitigen Änderungen in der Eingabe gefunden werden, teilen Sie dem Benutzer mit und stoppen Sie: „In dieser Eingabe wurden keine benutzerseitigen Änderungen gefunden. Es gibt nichts, worüber ein Newsletter geschrieben werden könnte.“

Fahren Sie NICHT fort, bis der Benutzer Umfang und Format bestätigt hat.

Phase 2: Konfiguration

Stellen Sie diese Fragen:

F1 – Zielgruppe: „An wen geht diese E-Mail?“ (alle Benutzer, Power-User, neue Benutzer, spezifische Tarifebene, Entwickler, nicht-technische Benutzer, andere)

F2 – Ausgabeformat: „In welchem Format möchten Sie die E-Mail?“

• Nur Text – Betreffzeile, Vorschautext, Fließtext, CTA-Text (in Ihr E-Mail-Tool einfügen)
• Markdown – formatiertes Markdown, das die meisten E-Mail-Tools importieren können

F3 – Ton: Lesen Sie vorhandene Repository-Inhalte (README, docs, Blogbeiträge), um die Stimme des Produkts zu erkennen. Bestätigen Sie dann:

„Basierend auf Ihren vorhandenen Inhalten scheint der Ton [z. B. gesprächig und entwicklerfreundlich] zu sein. Soll ich dem entsprechen oder eine andere Richtung einschlagen?“

Wenn keine vorhandenen Inhalte zur Analyse vorliegen, fragen Sie direkt, welchen Ton der Benutzer wünscht.

F4 – CTA: Leiten Sie den am besten geeigneten Call-to-Action aus dem Kontext ab:

• Neue Funktion -> „Jetzt ausprobieren“, „Entdecken Sie, was neu ist“
• Verbesserung -> „Anschauen“, „Den Unterschied sehen“
• Open Source -> „Jetzt aktualisieren“, „Das Release sehen“

„Ich schlage als CTA vor: [abgeleiteter CTA]. Möchten Sie damit weitermachen oder etwas anderes?“

Phase 3: Schreiben

Betreffzeilen

Generieren Sie 3–5 Betreffzeilenoptionen mit unterschiedlichen Ansätzen:

• Nutzenorientiert („Ihre Berichte werden jetzt als PDF exportiert“)
• Neugier („Wir haben die Suche neu aufgebaut“)
• Spezifischer Funktionsname („Dark Mode eingeführt“)
• Frage („Warten Sie immer noch auf den Export?“)
• Dringlichkeit/Aktualität („Diese Woche neu: 3 von Ihnen angefragte Funktionen“)

Empfehlen Sie eine und erklären Sie, warum sie am besten funktioniert. Erklären Sie auch die Kompromisse der anderen.

Regeln:

• 30–50 Zeichen optimal (vermeiden Sie abgeschnittene Anzeige auf Mobilgeräten)
• Seien Sie spezifisch, nicht generisch („Neu: PDF-Exporte“ ist besser als „Produkt-Update – März 2026“)
• Keine Spam-Triggerwörter (Kostenlos, Jetzt kaufen, Sofort handeln)

Vorschautext

Generieren Sie für jede Betreffzeilenoption einen Vorschautext. Der Vorschautext ist die sekundäre Zeile, die in Posteingangsvorschauen sichtbar ist.

Regeln:

• 40–130 Zeichen
• Erweitern Sie die Betreffzeile, wiederholen Sie sie nicht
• Enthalten Sie den Hauptnutzen oder das Ergebnis

E-Mail-Text

Struktur für Einzelfeature-E-Mail:

1. Problemstellung – ein Satz, der das Schmerzpunkt beschreibt, den dies löst
2. Was sich geändert hat – 2–3 Sätze, die das Update in nutzenorientierter Sprache beschreiben („Berichte laden schneller“ nicht „Optimierte SQL-Abfrageausführung“)
3. Bildplatzhalter – <!-- TODO: Screenshot oder GIF hinzufügen, das die Funktion in Aktion zeigt --> mit einer Beschreibung, was erfasst werden soll
4. CTA-Button – eine einzige klare Aktion

Struktur für Zusammenfassungs-E-Mail:

1. Hauptupdate – das wichtigste Update erhält die vollständige Einzelfeature-Behandlung (Problem, Änderung, Bild, CTA)
2. Sekundäre Updates – kurze Aufzählungspunkte mit einzeiligen Beschreibungen und Links
3. Schnellkorrekturen / Verbesserungen – gruppierte Liste kleinerer Änderungen
4. Abschließender CTA – eine einzelne Aktion oder „Alle Updates ansehen“

Schreibregeln

• Beginnen Sie mit dem Nutzen für den Benutzer, nicht mit dem, was Sie gebaut haben
• Gesprächiger Ton, nicht unternehmenslastig
• Kurze Absätze (max. 2–3 Sätze)
• Eine Idee pro Absatz
• Verwenden Sie niemals Gedankenstriche im generierten Inhalt. Keine „--“-Zeichen. Verwenden Sie stattdessen Kommas, Doppelpunkte, Punkte oder Klammern.
• Kein Fachjargon. „Berichte laden schneller“ ist besser als „Optimierter SQL-Abfrageausführungsplan“
• Heben Sie Schlüsselbegriffe durch Fettdruck hervor, um die Lesbarkeit zu verbessern
• Halten Sie es lesbar. Kürzer ist besser. Wenn das Lesen der E-Mail länger als 60 Sekunden dauert, ist sie zu lang.

Segmentvarianten

Fragen Sie nach der Erstellung der primären E-Mail:

„Möchten Sie, dass ich Varianten für verschiedene Zielgruppensegmente erstelle? (z. B. eine technischere Version für Entwickler, eine einfachere Version für nicht-technische Benutzer)“

Wenn ja, generieren Sie die angeforderten Varianten und passen Sie Ton, Tiefe und Funktionsschwerpunkte pro Segment an.

Phase 4: Überprüfung

Präsentieren Sie die vollständige E-Mail:

„Hier ist der Newsletter:“

Betreffzeilenoptionen: (mit Empfehlung und Vorschautext für jede)

1. Betreff: „...“ / Vorschautext: „...“
2. Betreff: „...“ / Vorschautext: „...“
3. Betreff: „...“ / Vorschautext: „...“

Text: [vollständiger E-Mail-Inhalt]

„Wählen Sie eine Betreffzeile aus und lassen Sie mich wissen, ob Sie Änderungen wünschen.“

Warten Sie, bis der Benutzer eine Betreffzeile auswählt und genehmigt oder Überarbeitungen anfordert. Fahren Sie erst nach der Genehmigung mit der Ausgabe fort.

Phase 5: Ausgabe

Geben Sie die endgültig genehmigte E-Mail immer im Terminal aus.

Fragen Sie dann: „Möchten Sie diese unter emails/<slug>.md speichern? Oder unter einem anderen Pfad?“

Erstellen Sie das Verzeichnis, falls es nicht existiert. Wenn die Datei bereits existiert, fragen Sie, ob sie überschrieben oder eine versionierte Kopie erstellt werden soll.

Fehlerbehandlung

• gh nicht verfügbar -> Benutzer informieren, alternative Eingabe anbieten
• Ungültige PR/Referenz -> Benutzer bitten, zu überprüfen
• Kein Produktkontext -> Benutzer bitten, das Produkt zu beschreiben
• Kein vorhandenes E-Mail-Verzeichnis -> Standardmäßig emails/ verwenden und erstellen

Was diese Fähigkeit NICHT tut

• E-Mails senden oder planen
• Abonnentenlisten oder Segmentierungslogik verwalten
• E-Mail-Vorlagen oder Designsysteme erstellen
• Blogbeiträge oder Social-Media-Texte generieren (verwenden Sie /blog-post oder /social-copy)