Blogbeitrag-Schreiber

Was macht Blogbeitrag-Schreiber?

Schreibe hochwertige Blogbeiträge aus Codeänderungen, Marketing-Briefs oder Feature-Beschreibungen. Handhabt SEO, Struktur, Tonanpassung und visuelle Inhalte.

Schreibregel (nicht verhandelbar): Verwende niemals Gedankenstriche (— or –). Verwende stattdessen einen Bindestrich -. Gilt für jede Zeile des generierten Texts.

Eingabeauflösung

Löse das Argument (falls vorhanden) in dieser Reihenfolge auf:

1. Pfad zu einer vorhandenen Marketing-Brief-Datei (.md mit „Executive Summary“ oder „Key Messages“) → Marketing-Brief
2. Entspricht GitHub-URL oder Muster #\d+ → PR
3. Enthält ... or .. → Git-Referenzbereich
4. Wird zu vorhandener Datei/Verzeichnis aufgelöst → Codebase-Feature
5. Andernfalls → Freitext

Wenn kein Argument angegeben wird, frage: „Worüber soll ich schreiben? Du kannst einen Pfad zu einem Marketing-Brief, eine PR-URL/-nummer, einen Git-Referenzbereich (z.B. v1.0...v2.0), einen Datei-/Verzeichnispfad oder einfach das Thema beschreiben.“

Wenn mehrere Interpretationen zutreffen, frage den Benutzer zur Bestätigung.

Prozessablauf

digraph blog_post {
    rankdir=TB;
    "Resolve input" [shape=box];
    "Phase 1: Discovery" [shape=box];
    "Phase 2: Research" [shape=box];
    "Phase 3: Configure" [shape=box];
    "Phase 4: Outline" [shape=box];
    "Outline approved?" [shape=diamond];
    "Phase 5: Write" [shape=box];
    "Phase 6: Output" [shape=box];

    "Resolve input" -> "Phase 1: Discovery";
    "Phase 1: Discovery" -> "Phase 2: Research";
    "Phase 2: Research" -> "Phase 3: Configure";
    "Phase 3: Configure" -> "Phase 4: Outline";
    "Phase 4: Outline" -> "Outline approved?";
    "Outline approved?" -> "Phase 4: Outline" [label="nein, überarbeiten"];
    "Outline approved?" -> "Phase 5: Write" [label="ja"];
    "Phase 5: Write" -> "Phase 6: Output";
}

Überspringe KEINE Phasen. Stelle Fragen in einem natürlichen Tempo. Überwältige nicht, aber bremse auch nicht unnötig. Wenn der Benutzer mehrere Fragen auf einmal beantwortet, akzeptiere die gebündelten Antworten und springe vor.

Wenn der Benutzer sagt „wähle einfach Standardwerte“, „entscheide du“ oder ähnliches, wähle sinnvolle Standardwerte basierend auf dem Kontext, teile mit, was du gewählt hast, und bitte vor dem Fortfahren um eine einzige Bestätigung.

Triff niemals Annahmen ohne Bestätigung.

Phase 1: Discovery

Schritt 1 - Analysiere die Eingabe

Eingabetyp	Was zu lesen
Marketing-Brief	Den Brief lesen - Problemstellung, Wertversprechen, Zielgruppe, Kernbotschaften, Wettbewerbsposition extrahieren. Schritt 2 trotzdem durchführen, wenn dem Brief Produktkontext fehlt, dann mit Schritt 3 fortfahren.
PR	Diff, PR-Beschreibung, Review-Kommentare, Commit-Nachrichten (gh pr view, gh pr diff). Bei großen PRs (20+ Dateien) auf benutzernahe Änderungen fokussieren.
Git-Referenzen	git diff und git log zwischen den Referenzen. Bei großen Bereichen Commit-Nachrichten und benutzernahe Änderungen priorisieren.
Codebase-Feature	Die angegebenen Dateien/Verzeichnisse lesen.
Freitext	Die Beschreibung des Benutzers parsen. Wenn es an Details mangelt (kein Feature-Name, kein Wertversprechen, kein Kontext), den Benutzer bitten, mehr Details zu liefern oder auf eine bestimmte Datei/PR zu verweisen. Nur als letzten Ausweg auf offene Fragen zurückgreifen.

Benutzernahe Änderungen umfassen: neue Features, UI-Änderungen, API-Änderungen, Leistungsverbesserungen, Fehlerbehebungen und Dokumentationsaktualisierungen. Interne Änderungen umfassen: Refaktorisierungen, Test-Ergänzungen, CI-Änderungen und Abhängigkeitsaktualisierungen. Im Zweifelsfall auflisten, was du gefunden hast, und den Benutzer fragen, welche relevant sind.

Fehlerbehandlung:

• gh nicht installiert/authentifiziert → Benutzer informieren, gh auth login vorschlagen, alternative Eingabe anbieten
• Ungültige PR/Referenz → Benutzer informieren, um Überprüfung bitten
• Datei nicht gefunden → nach dem richtigen Pfad fragen

Schritt 2 - Breiteren Produktkontext lesen

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

Ziel: verstehen, was das Produkt ist, für wen es ist und was es tut.

Wenn nichts gefunden wird, frage: „Ich konnte im Repository keinen Produktkontext finden. Kannst du das Produkt kurz beschreiben und für wen es ist?“

Schritt 3 - Verständnis präsentieren

„Hier ist, was ich verstanden habe:“

• Feature A – kurze Beschreibung
• Feature B – kurze Beschreibung

„Welche davon soll der Blogbeitrag abdecken? Soll ich etwas hinzufügen, entfernen oder korrigieren?“

Stelle so viele Fragen wie nötig, um den Umfang vollständig zu verstehen. Fahre NICHT fort, bis der Benutzer bestätigt.

Schritt 4 - Sensible Elemente kennzeichnen

Prüfe auf: Breaking Changes, Deprekationen, Sicherheitskorrekturen, Migrationsanforderungen.

Wenn gefunden, jedes kennzeichnen und fragen, wie es dargestellt werden soll, bevor du fortfährst.

Phase 2: Wettbewerbs-Blog-Recherche

Bevor du den Beitrag konfigurierst, suche nach ähnlichen Blogbeiträgen in diesem Bereich:

1. Verwende WebSearch, um 3-5 bestehende Blogbeiträge zum gleichen Thema, zu Konkurrenzprodukten oder ähnlichen Feature-Ankündigungen zu finden
2. Analysiere, was in diesen Beiträgen funktioniert und was nicht – Struktur, Überschriften, Hooks, SEO-Keywords, Tiefe
3. Identifiziere Content-Lücken – was decken die Wettbewerber NICHT ab, was dieser Beitrag könnte
4. Nutze diese Erkenntnisse für die SEO-Strategie, Überschriften-Generierung und Inhaltsstruktur

Wenn WebSearch nicht verfügbar ist, überspringe diese Phase und verlasse dich auf dein eigenes Wissen.

Präsentiere eine kurze Zusammenfassung für den Benutzer:

„Ich habe einige ähnliche Beiträge in diesem Bereich gefunden. Hier ist mir aufgefallen:“

• [Wichtigste Erkenntnisse, was funktioniert]
• [Content-Lücken / Chancen]
• [SEO-Keyword-Chancen]

„Ich werde diese Erkenntnisse nutzen, um den Beitrag zu gestalten.“

Phase 3: Konfiguration

Stelle diese Fragen:

F1 - Zielgruppe: „Für wen ist dieser Blogbeitrag?“ (Entwickler, Endbenutzer, technische Entscheidungsträger, allgemeines Publikum, sonstiges)

F2 - Ton: Lies bestehende Blogbeiträge, README und Dokumentation im Repository, um die Stimme des Produkts zu erkennen. Bestätige dann:

„Basierend auf deinen bestehenden Inhalten wirkt der Ton [z.B. gesprächig und entwicklerfreundlich]. Soll ich ihn anpassen oder einen anderen Richtung gehen?“

Wenn keine bestehenden Inhalte zur Analyse vorhanden sind, frage direkt, welchen Ton der Benutzer wünscht.

F3 - Beitragstyp: Basierend auf der Eingabe und Zielgruppe einen Beitragstyp empfehlen und bestätigen lassen:

• Feature-Ankündigung – „Wir haben X veröffentlicht, warum es wichtig ist“ (~600-1000 Wörter)
• Technischer Deep-Dive – „Wie wir X gebaut haben, die Entscheidungen und Architektur“ (~1500-2500 Wörter)
• Problem-Lösungs-Erzählung – „Du hast Problem X, hier ist, wie es gelöst wird“ (~1000-2000 Wörter)

„Angesichts der [Eingabe/Zielgruppe] würde ich einen [Typ]-Beitrag empfehlen, weil [Grund]. Klingt das richtig?“

F4 - CTA: Leite den am besten geeigneten Call-to-Action aus dem Kontext ab:

• Open Source → Repository starren, beitragen, ausprobieren
• SaaS → anmelden, kostenlose Testversion starten
• Feature-Update → das neue Feature ausprobieren, die Dokumentation lesen
• Bibliothek/SDK → installieren, den Migrationsleitfaden lesen

„Ich würde den CTA vorschlagen: [abgeleiteter CTA]. Möchtest du das so oder etwas anderes?“

F5 - Beteiligungsgrad: „Wie stark möchtest du in den Schreibprozess eingebunden sein?“

• A) Schreib es einfach – Ich kümmere mich um alles, wähle die beste Überschrift und speichere den endgültigen Beitrag. Du kannst danach Änderungen anfordern.
• B) Zeig mir zuerst die Gliederung – genehmige die Struktur, dann schreibe ich den vollständigen Beitrag
• C) Führ mich Schritt für Schritt – Gliederungsgenehmigung, dann abschnittsweise mit Bestätigung

Phase 4: Gliederung

Erzeuge eine strukturierte Gliederung:

## [Arbeitstitel]

1. **Haken/Einleitung** – [Ansatz: Frage/Statistik/kühne Aussage/Geschichte]
   - Wichtiger Punkt zu etablieren
   - Übergang zum Hauptteil

2. **Abschnittsname** – [Zweck]
   - Kernpunkte
   - Geschätzte Wortanzahl

3. **Abschnittsname** – [Zweck]
   - Kernpunkte
   - Geschätzte Wortanzahl

[...beliebig viele Abschnitte]

N. **Fazit** – [Zusammenfassung + CTA]
   - Wichtigste Erkenntnis zur Untermauerung
   - CTA: [spezifische Aktion]

Geschätzte Gesamtanzahl: ~X Wörter

Wenn Beteiligungsgrad A ist, generiere die Gliederung intern ohne sie anzuzeigen. Bei B und C präsentiere sie und warte auf Genehmigung.

Phase 5: Schreiben

Interner Schreibprozess (läuft immer, unabhängig vom Beteiligungsgrad)

Für jeden Abschnitt:

1. Abschnitt schreiben
2. Selbstprüfung: Analysiere, ob der Inhalt anders strukturiert werden könnte, ob dem Leser Kontext zum Verständnis und zur Aufnahme fehlt, oder ob Lücken bestehen, die jemanden verwirren würden, der mit dem Thema nicht vertraut ist
3. Nachfüllen: Wenn fehlende Teile gefunden werden, füge überleitende Absätze, Kontext hinzu oder strukturiere um, bevor du fortfährst

Wenn Beteiligungsgrad C ist, präsentiere jeden Abschnitt nach der Selbstprüfung und hole dir die Bestätigung, bevor du fortfährst. Bei A und B führe diesen Prozess stillschweigend aus.

Überschriften

Nachdem der Haupttext fertig ist, generiere 3-5 Überschriften-Optionen mit verschiedenen Formeln:

• Anleitung („Wie [Produkt] [Problem] löst“)
• Zahl/Liste („3 Gründe, warum [Feature] [Workflow] ändert“)
• Frage („Hast du genug von [Schmerzpunkt]?“)
• Kühne Aussage („[Feature] ist der schnellste Weg zu [Ergebnis]“)
• Vorher/Nachher („[Schmerz] → [Ergebnis]: Wie [Feature] es möglich macht“)

Empfehle eine und erkläre, warum sie für die Zielgruppe, SEO und den Kontext dieses Beitrags am besten geeignet ist. Erkläre auch die Kompromisse der anderen.

Für Beteiligungsgrade B und C präsentiere die Optionen und lasse den Benutzer auswählen, bevor du fortfährst. Bei Grad A verwende deine Empfehlung.

Priorisiere Lesbarkeit vor SEO-Beschränkungen. Schreibe zuerst die beste Überschrift. Wenn sie nicht in das 50-60-Zeichen-SEO-Titel-Limit passt, erstelle einen separaten kürzeren Titel-Tag für die Frontmatter.

SEO-Frontmatter

Generiere als YAML-Frontmatter am Anfang des Beitrags:

---
title: "[Ausgewählte Überschrift]"
meta_description: "[140-160 Zeichen, enthält primäres Keyword, überzeugendes Wertversprechen]"
primary_keyword: "[Haupt-Zielkeyword]"
secondary_keywords: ["keyword1", "keyword2", "keyword3"]
long_tail_keywords: ["längere Phrase 1", "längere Phrase 2"]
slug: "[url-freundlicher-slug]"
---

Regeln:

• Titel-Tag: 50-60 Zeichen, primäres Keyword vorne
• Meta-Beschreibung: 140-160 Zeichen, für Menschen geschrieben, enthält einzigartiges Wertversprechen
• Keywords basierend auf Phase-2-Wettbewerbsrecherche
• Kein Keyword-Stuffing – nur natürliche Sprache

Formatierungsregeln für Inhalte

• Kurze Absätze: Maximal 2-4 Sätze
• Zwischenüberschriften: H2 für Hauptabschnitte, H3 für Unterabschnitte. Zwischenüberschriften sollten für sich genommen als überfliegbare Gliederung funktionieren.
• Schlüsselphrasen fett zur Unterstützung des F-Muster-Scannens
• Aufzählungspunkte und Listen für jede Menge von 3+ Elementen
• Eine Idee pro Absatz
• Verwende niemals Gedankenstriche im generierten Inhalt. Keine „—“-Zeichen. Verwende stattdessen Kommas, Doppelpunkte, Punkte oder Klammern.

Haken/Einleitung

Die Einleitung besteht aus drei Komponenten:

1. Haken (erste 1-2 Sätze) – eine überraschende Statistik, kühne Behauptung, nachvollziehbarer Schmerzpunkt oder provokative Frage. Muss in unter 3 Sekunden Lesezeit Neugier oder emotionale Resonanz erzeugen.
2. Autorität – kurz etablieren, warum dies wichtig ist oder warum der Leser vertrauen sollte
3. Versprechen – klar angeben, was der Leser aus diesem Beitrag mitnimmt

Halte die Einleitung auf 3-5 kurze Absätze. Keine Textwände.

Fazit

1. Wiederhole die wichtigste Erkenntnis (führe KEINE neuen Ideen ein)
2. Einziger, klarer CTA mit Aktionsverb („Jetzt ausprobieren“, „Repository starren“, „Kostenlose Testversion starten“)
3. Optional mit einer zukunftsgerichteten Aussage oder Frage enden, um eine Diskussion anzuregen

Visuelle Inhalte

Direkt generieren, wenn möglich:

• Architekturdiagramme → Mermaid-Codeblöcke oder Inline-SVG
• Datenflussdiagramme → Mermaid-Codeblöcke
• Vergleichstabellen → Markdown-Tabellen
• Codebeispiele → Syntax-hervorgehobene Codeblöcke

Für Bilder, die externe Erstellung benötigen:

<!-- TODO: Hier Bild einfügen -->
<!-- Vorschlag: [Beschreibung, was das Bild zeigen soll] -->
<!-- LLM-Prompt: [fertiger Prompt für ein Bildgenerierungsmodell, z.B. „Eine saubere, minimalistische Illustration eines Dashboards mit Dark-Mode-Umschalter, flacher Designstil, Entwickler-Tool-Ästhetik, 16:9“] -->
![Alt-Text-Beschreibung](placeholder.png)

Verwende visuelle Elemente, wo sie das Verständnis fördern – nach der Erklärung eines komplexen Konzepts, beim Vergleich von Optionen oder bei der Darstellung von UI-Änderungen.

Codebeispiele

Für Entwicklerzielgruppen mindestens ein Codebeispiel einfügen, das das Feature in Aktion zeigt. Bevorzuge minimale, ausführbare Schnipsel (5-15 Zeilen). Zeige Vorher/Nachher, wenn eine Verbesserung demonstriert wird.

Phase 5b: Vollständige Entwurfsprüfung

Nachdem alle Abschnitte geschrieben und die Überschrift ausgewählt wurde, setze den vollständigen Beitrag zusammen (Frontmatter + Haupttext).

• Grad A: Überspringe die Prüfung. Fahre direkt mit der Ausgabe fort. Präsentiere den endgültigen Beitrag und speichere ihn. Der Benutzer kann danach Änderungen anfordern.
• Grad B: Präsentiere den vollständigen Entwurf dem Benutzer zur Prüfung, bevor du ihn speicherst. „Hier ist der vollständige Beitrag. Möchtest du vor dem Speichern noch Änderungen?“
• Grad C: Der Benutzer hat jeden Abschnitt einzeln gesehen, aber präsentiere dennoch den zusammengesetzten Entwurf für eine abschließende Prüfung. „Hier ist der vollständige Beitrag. Möchtest du vor dem Speichern noch Änderungen?“

Für B und C, wenn der Benutzer Überarbeitungen anfordert, führe sie durch und präsentiere sie erneut. Fahre nur mit der Ausgabe fort, wenn der Benutzer zustimmt.

Phase 6: Ausgabe

Erkenne zuerst das vorhandene Blog-Verzeichnis. Suche nach:

• content/blog/, src/pages/blog/, _posts/, blog/, posts/, articles/

Wenn gefunden, verwende dieses Verzeichnis. Wenn nicht, verwende standardmäßig blog/posts/.

Präsentiere dem Benutzer:

„Ich speichere das unter [erkanntes-oder-standard-pfad]/<slug>.md. Möchtest du es woanders speichern oder soll ich das Speichern überspringen und es nur ausgeben?“

Erstelle das Verzeichnis, falls es nicht existiert.

Wenn die Datei bereits existiert: frage, ob ü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
• WebSearch nicht verfügbar → Phase 2 überspringen, mit eigenem Wissen fortfahren
• Kein vorhandenes Blog-Verzeichnis → Standard blog/posts/ verwenden, es erstellen

Was diese Fähigkeit NICHT tut

• Social-Media-Texte generieren (dafür /social-copy verwenden)
• Den Beitrag auf einer Plattform veröffentlichen oder bereitstellen
• Marketing-Briefs generieren (dafür /marketing-brief verwenden)
• Mehrere Varianten für verschiedene Zielgruppen erstellen – die Fähigkeit für eine andere Zielgruppe erneut ausführen