Wie ich eine Pipeline für Blogposts mit parallelen Kritikern gebaut habe

Absicht

Ich wollte meine Skill zum Schreiben von Blogposts ausbauen. Inspiriert hat mich ein Artikel über eine Content Pipeline — dort wird das Format der “Gesprächsdokumentation” verwendet, wo der Autor nicht nur das Ergebnis, sondern auch den Prozess zeigt. Ich wollte das nicht einfach kopieren, sondern ein modulares System bauen:

• Pipeline aus 5 Phasen mit Agenten-Orchestrierung
• Integration von Exa AI für Recherchen
• Zwei Artikelformate (Standard und Conversational)
• Möglichkeit, die Skill auf verschiedenen Sites wiederzuverwenden

Die Hauptidee: statt sequenzieller Editierdurchläufe spezialisierte Agenten parallel starten. Wie das Fan-out/Fan-in-Muster in verteilten Systemen — ich verteile die Arbeit, sammle die Ergebnisse.

Versuche

Erste Iteration: Struktur

Ich begann mit einer modularen Struktur:

/Users/ilya/.claude/skills/blogpost-pipeline/
├── phases/
│   ├── 01-questions.md
│   ├── 02-research.md
│   ├── 03-draft.md
│   ├── 04-critics.md
│   └── 05-deploy.md
├── formats/
│   ├── standard.md
│   └── conversation.md
└── config/
    ├── sites.yaml
    └── eo-os.yaml

Jede Phase ist eine separate Datei mit Anweisungen. Die Formate beschreiben die Artikelstruktur. Die Configs enthalten die Besonderheiten jeder Site.

Zweite Iteration: 5 Phasen

Ich entwarf die Pipeline:

1. Questions — dem Nutzer Fragen zu Thema, Zielgruppe, Format und Ziel-Site stellen
2. Research — Material über Exa AI (semantische Suche) und Websuche sammeln
3. Draft — Entwurf im gewählten Format schreiben
4. Critics — 4 parallele Kritiker starten, Feedback sammeln, Korrekturen anwenden
5. Deploy — im richtigen Verzeichnis speichern, Vorschau per Telegram senden

Die vierte Phase unterscheidet sich von den anderen. Statt eines Editors — 4 spezialisierte Agenten arbeiten gleichzeitig:

AI Slop Detector    ─┐
Rhythm Analyzer     ─┼─► Merge ─► Final edits
Specificity Checker ─┤
Fact Checker        ─┘

Der AI Slop Detector sucht Klischees (“dive into”, “it’s worth noting”). Der Rhythm Analyzer prüft den Fluss und die Variation der Satzlängen. Der Specificity Checker ersetzt vage Formulierungen durch konkrete Beispiele. Der Fact Checker fordert Belege für Behauptungen.

Alle vier schauen sich denselben Text parallel an. Dann sammle ich ihr Feedback und nehme die Korrekturen in einem einzigen Durchlauf vor. Wenn zwei Kritiker sich widersprechen — kläre ich das manuell.

Dritte Iteration: Site-Configs

Ich erstellte Configs für drei Sites in config/sites.yaml:

sites:
  igindin:
    path: apps/igindin-blog/drafts/
    telegram_channel: "@igindin_blog"

  t4s:
    path: apps/t4s-club/content/blog/
    telegram_channel: "@t4s_club"

  eo-os:
    path: apps/eo-os/content/articles/
    auto_publish: true

Eine Skill liest die Config und weiß, wo gespeichert und wie benachrichtigt werden soll.

Wendungen

Problem 1: doppelte Skills

Als ich die neue Skill startete, erschienen zwei /blogpost-Befehle in der Liste:

• Alte Skill (4-Pass-Ansatz)
• Neue Skill (5-Phasen-Pipeline)

Verwirrend. Ich löschte die alte:

rm -rf "/Users/ilya/[vibecoding]/.claude/skills/blogpost"

Problem 2: content-factory war ebenfalls ein Duplikat

Es stellte sich heraus, dass content-factory eine alte Version ähnlicher Funktionalität war. Ich löschte sie ebenfalls. Danach war die Skills-Liste sauber.

Problem 3: die Skill stellte keine Fragen

Die erste Version begann sofort zu schreiben und überging die Fragephase. Der Artikel enthielt keinen Kontext — 2000 Wörter generischer Phrasen wie “KI ist ein mächtiges Werkzeug”.

Ich fügte am Anfang der SKILL.md hinzu:

## CRITICAL: Start with Questions

**DO NOT start writing immediately.**

Before ANY writing, you MUST use AskUserQuestion to gather context:
1. Topic & angle
2. Audience
3. Format (standard/conversation)
4. Target site

Only after receiving answers → proceed to research and writing.

Jetzt beginnt die Skill immer mit einem Dialog. Die ersten 2-3 Minuten sind Fragen, dann ein fertiges Ergebnis beim ersten Versuch.

Ergebnis

Am Ende entstand ein funktionierendes System:

• 5-Phasen-Pipeline — von Fragen bis zum Deploy
• Modularität — Formate und Configs werden wiederverwendet
• Symlinks — eine Skill in ~/.claude/skills/blogpost-pipeline/, Symlinks in jedem Projekt
• Sauberkeit — keine Duplikate
• Obligatorische Fragen — die Skill schreibt nicht blind

Ich starte /blogpost, beantworte 3-4 Fragen, erhalte den Artikel im richtigen Format für die richtige Site.

Fazit

Parallele Kritiker sind Fan-out/Fan-in für Text.

Der klassische Ansatz beim Editieren ist sequenziell: Entwurf → Struktur → Stil → Fakten → abschließendes Polieren. Jeder Durchlauf wartet auf den vorherigen.

Neuer Ansatz: Entwurf → [4 gleichzeitige Agenten] → eine zusammengeführte Korrektur. Schneller und gründlicher, weil die Agenten sich nicht gegenseitig beeinflussen und keine Probleme übersehen, die “der vorherige schon behoben hat”.

Als ich die vier Kritiker auf diesen Entwurf losließ, fanden sie:

• 7 Stellen mit Hedging-Wörtern (“vielleicht”, “irgendwie”)
• 3 monotone Listen mit gleichlangen Punkten
• 5 abstrakte Behauptungen ohne Beispiele
• 2 technische Ungenauigkeiten

Manuell hätte ich 30-40 Minuten für 4 Durchläufe gebraucht. Die parallelen Agenten erledigten das in 2 Minuten.

---

Dieser Artikel wurde von der Skill geschrieben, die er beschreibt.