Blog-Pipeline (kingadow/blog-pipeline)

Blog-Pipeline

Was du bekommst: einen Beitrag, der eine echte Suchanfrage beantwortet, in deinem Stil verfasst, mit geprüften Fakten, einem 1200×630-Bild und gültigem Frontmatter – zur Überprüfung bereit in einem eigenen Ordner.

Erster Schritt: platziere eine ausgefüllte BLOG.md im Stammverzeichnis deines Projekts (die Vorlage befindet sich in diesem Repository). Jede Phase liest diese Datei.

Zuerst lesen – jedes Mal

1. BLOG.md im Projektstamm: Website, Leser, Ziel, Stimme, zu vermeidende Wörter, Kategorien, Veröffentlichungsfrequenz, SEO- und Bildregeln, Frontmatter-Standardwerte und die Korrekturliste. Wo BLOG.md und diese Skill widersprechen, hat BLOG.md Vorrang.
2. references/frontmatter-contract.md, bevor du Frontmatter schreibst.
3. Die Referenzdatei für die Phase, die du ausführst – und sonst nichts, was du nicht brauchst.

Noch keine BLOG.md? Stoppe und biete an, eine zu erstellen. Lies 3 bis 5 bestehende Beiträge oder Seiten der Person, stelle die Fragen aus jedem Abschnitt der Vorlage, schreibe die Datei und bitte sie, sie zu überprüfen. Ein ohne BLOG.md geschriebener Beitrag klingt nach niemand Bestimmtem.

Wie es funktioniert

Ein Blogbeitrag ist die Antwort auf etwas, das eine Person in Google eingibt. Das Wissen kann aus einem Vortrag, einem Newsletter oder einem Kundengespräch stammen; der Beitrag baut es um eine einzige Suchanfrage herum auf: ein Titel, der der Suche entspricht, die Antwort nahe am Anfang, Überschriften, die so formuliert sind, wie Leute suchen.

Aktualisiere, bevor du Neues schreibst. Prüfe, ob ein bestehender Beitrag oder eine Seite bereits auf die Suche ausgerichtet ist. Ein Beitrag, den Google bereits anzeigt, mit Aufrufen und ohne Klicks, ist mehr wert als ein neuer Beitrag von null und erfordert einen Bruchteil der Arbeit. Zwei Seiten, die auf eine Suche abzielen, verlieren meist beide.

Der Arbeitsordner

Ein Ordner pro Beitrag, im Projekt der Person: posts/<YYYY-MM-DD>-<slug>/. Das Datum ist der geplante Veröffentlichungstag. Der Slug ist die endgültige Adresse und der Dateiname. Jede Phase schreibt eine Datei in den Ordner, sodass der Ordner das Gedächtnis ist: Jede Phase kann erneut ausgeführt oder später fortgesetzt werden, ohne die vorherigen Phasen zu wiederholen.

#	Phase	Liest	Schreibt	Anleitung
1	Ideenfindung	BLOG.md, Suchdaten, bestehende Beiträge und Seiten	posts/_ideas/topic-ideas.md	references/01-ideation.md
2	Briefing	ein Thema	brief.md	references/02-brief.md
3	Recherche	brief.md	research.md	references/03-research.md
4	Entwurf	research.md, brief.md, BLOG.md	draft.md	references/04-draft.md
5	visuelle Elemente	draft.md	visuals.md, <slug>.svg, <slug>.png	references/05-visuals.md
6	Veröffentlichung	draft.md, visuals.md	der Beitrag in src/content/blog/, Bilder in public/images/blog/, publish.md	references/06-publish.md

Die gesamte Kette: Phasen 2 bis 6 der Reihe nach für ein Thema. Phase 1 ist ein Batch-Schritt: Führe ihn aus, wenn die Ideenliste zur Neige geht, etwa einmal im Monat bei wöchentlicher Kadenz.

„Plane meinen ersten Beitrag“ (oder „Plane meinen nächsten Beitrag“): Phase 1, dann Phase 2. Führe die Ideenfindung durch, zeige die Shortlist, lass die Person ein Thema auswählen (es muss nicht #1 sein; notiere die Auswahl und den Grund in topic-ideas.md), schreibe dann das Briefing. Stoppe nach dem Briefing und sage, welche Phase als nächstes kommt. Wenn die Person darum bittet, „Themenideen zu finden“, führe nur Phase 1 aus; wenn sie darum bittet, „das Briefing für zu schreiben“, führe nur Phase 2 aus.

Eine Phase: Die Person nennt die Phase und den Beitrag. Lies die Datei dieser Phase und ihre Eingaben und überspringe den Rest.

Eine Aktualisierung: Überspringe die Phasen 1 und 2. Erstelle den Ordner posts/<heute>-<slug>-refresh/, führe Phase 3 und Phase 4 im Aktualisierungsmodus aus, dann Phase 6.

Die Pfade oben beziehen sich auf die Starter-Site. Wenn BLOG.md andere Ordner auflistet, verwende diese.

Regeln

Diese Regeln haben Vorrang vor jeder Phasendatei. BLOG.md kann weitere hinzufügen.

1. Erfinde niemals eine Quelle, Statistik, ein Zitat oder einen Link. Jede URL in einem Beitrag wurde während der Recherche geöffnet. Eine Behauptung, die du nicht überprüfen kannst, wird gestrichen oder mit [UNVERIFIED] markiert, damit die Person sie bestätigt. Die eigene Erfahrung der Person zählt als Quelle, wenn sie als solche gekennzeichnet ist. Eine Zahl aus ihrer Arbeit benötigt eine Datei im Projekt oder ein datiertes Chat-Zitat, das in research.md (Phase 3) festgehalten wird; ohne eines ist sie [UNVERIFIED] und bleibt aus der veröffentlichten Datei heraus.
2. Überprüfe Fakten zu Tools und Plattformen anhand der aktuellen Dokumentation. Funktionen und Grenzen ändern sich, und die Anleitung von letztem Jahr ist heute oft falsch.
3. Suchzahlen sind Daten oder sie sind gekennzeichnet. Volumen und Schwierigkeit stammen aus einem Tool, das jemand ausgeführt hat, mit Datum, oder die Datei sagt „unschätzbar“. Eine geschätzte Zahl, die als Daten präsentiert wird, ist schlimmer als keine Zahl.
4. Die Person überprüft jeden Entwurf, bevor er veröffentlicht wird. Neue Beiträge erhalten draft: true. Die Skill pusht, deployed oder schaltet draft niemals selbst um. Die einzige Ausnahme ist die Aktualisierung eines veröffentlichten Beitrags, der draft: false behält (siehe Phase 6).
5. Genehmigung: wann, wie und wo Bearbeitungen erfolgen. Dies ist der einzige Ort, an dem die Skill dies definiert; Phase 6 folgt dem.
   • Wann: jederzeit, nachdem Phase 6 die veröffentlichte Datei geschrieben hat und die Person den Beitrag gelesen hat. Die gleiche Sitzung ist in Ordnung.
   • Wie: eine Änderung. Die Person setzt draft: false in src/content/blog/<slug>.md oder sagt Claude, er solle es tun. Bestätige gleichzeitig, dass date der Veröffentlichungstag ist.
   • Wo Bearbeitungen erfolgen: vor Phase 6 in posts/<ordner>/draft.md. Nach Phase 6 nur in der veröffentlichten Datei. draft.md bleibt als der übergebene Entwurf, und publish.md listet jede nachträglich vorgenommene Änderung auf.
   • Was es aufhält: Alles, was vor dem Datum noch zu tun ist (eine fehlende Seite, eine [UNVERIFIED]-Behauptung, eine Zeile, die der Link-Audit ausgibt), hält den Beitrag auf draft: true, bis es erledigt ist.
6. Das Datum ist das Veröffentlichungs-Gate. Die Starter-Site hält einen zukünftig datierten Beitrag bis zu seinem Tag versteckt und listet ihn unter „Ausstehende Beiträge“.
7. Kundenarbeit bleibt anonym, es sei denn, der Kunde hat einer Nennung zugestimmt. Die Entfernung des Namens ist der Anfang: Überprüfe Kombinationen von Kategorie, Ort und Zeitpunkt, die sie immer noch identifizieren („ein Kerzenladen in Vermont, der im März eröffnet hat“ ist ein Name). Wandle Einnahmen in Verhältnisse oder Prozentsätze um.
8. Antworte zuerst. Ein Takt Kontext, den der Leser aus seiner eigenen Arbeit wiedererkennt, dann die Antwort bis zum Ende des dritten Absatzes. Eine Frage eröffnet niemals einen Beitrag.
9. Schreibe für die Suche, mit einem Aufruf zum Handeln. Überschriften formuliert, wie Leute suchen, Ziffern für Zahlen, kurze Absätze. Die Hauptaktion ist diejenige in Abschnitt 3 von BLOG.md und entspricht cta in src/site.config.mjs. Die Starter-Site zeigt diesen Button mit einem Anmeldefeld am Ende jedes Beitrags, daher braucht der Textkörper keinen abschließenden Call-to-Action-Link. Der Textkörper darf einmal im Text auf die Hauptaktion verlinken, nur wenn es zum Beitrag passt, und nur auf eine Seite, die existiert, oder auf die cta-Adresse.
10. Verlinke nur auf Seiten, die am Veröffentlichungstag des Beitrags live sind. Das bedeutet jeder Link zur eigenen Domain der Site, sowohl Beiträge als auch Seiten. Schreibe Links zur eigenen Site als relative Links (/about/). Phase 6 enthält die Überprüfung.
11. Die Stimme gehört der Person. Ein Entwurf, der wie kompetenter Content eines Fremden klingt, ist gescheitert, selbst wenn jede Regel erfüllt ist.

Korrekturen werden zu Regeln

Wenn die Person dieselbe Sache zweimal korrigiert (ein Wort, einen Einstieg, einen Überschriftenstil), biete an, eine datierte Zeile im Korrekturabschnitt von BLOG.md hinzuzufügen. Phase 4 liest diesen Abschnitt vor jedem Entwurf, sodass eine einmal vorgenommene Korrektur dauerhaft bleibt.

Vor der Übergabe eines Entwurfs

Durchsuche den Entwurf nach jedem Wort aus BLOG.mds „Zu vermeidende Wörter“, zum Beispiel:

grep -n -i -E "wort eins|wort zwei|—" posts/<ordner>/draft.md

Eine Wortsucher übersieht Satzformen. Führe die Formensuche in Phase 4 durch („Formen, die eine Wortsucher übersieht“), lies den Entwurf dann einmal auf die Formen, die BLOG.md auflistet und die keine Suche erfasst, wie eine einleitende Frage oder eine abschließende Zusammenfassung. Überprüfe auch jeden faktischen Satz mit research.md (Phase 4).

Informiere dann die Person in wenigen Zeilen: wo sich der Entwurf befindet, die Zielsuche, das geplante Datum, alles, was mit [UNVERIFIED] markiert ist, etwaige Vertraulichkeitsfragen und was sie entscheiden muss.

Optional: Eine Newsletter-Version

Wenn die Person auch einen Newsletter veröffentlicht (Substack, Beehiiv, Kit oder ähnlich), kann dasselbe Wissen dort verbreitet werden. Gib der Newsletter-Version einen eigenen Titel und eine eigene Suchphrase, damit die 2 Seiten nicht in Google konkurrieren, und füge das Newsletter-Archiv zur Überlappungsprüfung in den Phasen 1 und 2 hinzu.

Werkzeuge

Claude Code oder Claude mit Zugriff auf die Dateien des Projekts. Suchdaten stammen von kostenlosen Tools: Google Autocomplete, Google Search Console, dem kostenlosen Ubersuggest-Plan und einer einfachen Google-Suche für die erste Seite. Wenn kein Tool verbunden ist, bitte die Person, das einzufügen, was sie sieht (Ubersuggest funktioniert auf seiner Website gut) oder markiere die Zahl als nicht geschätzt. Eine neue Site ohne Daten und ohne Tools kann trotzdem fortfahren: references/01-ideation.md enthält den Weg.

Kein Webzugriff in dieser Sitzung: Phase 1 bewertet Ideen basierend auf den vorhandenen Beweisen und markiert den Rest als „nicht geprüft“. Die Person fügt die Autocomplete-Vorschläge und die erste Seite für die eine ausgewählte Zielsuche in Phase 2 ein, bevor das Briefing genehmigt wird. Niemand fügt etwas für die gesamte Shortlist ein. Halte API-Schlüssel aus BLOG.md und aus den Beitragsordnern fern.