Как я собрал конвейер для блогпостов с параллельными критиками

Намерение

Я хотел расширить свой скилл для написания блогпостов. Вдохновился статьёй про content pipeline — там используется формат “документирование разговоров”, где автор показывает не только результат, но и процесс. Хотелось не просто скопировать, а сделать модульную систему:

• Пайплайн из 5 фаз с оркестрацией агентов
• Интеграция Exa AI для исследований
• Два формата статей (стандартный и conversational)
• Возможность переиспользовать скилл на разных сайтах

Главная идея: вместо последовательных проходов редактирования запускать специализированных агентов параллельно. Как fan-out/fan-in паттерн в distributed systems — распределяю работу, собираю результаты.

Попытки

Первая итерация: структура

Начал с создания модульной структуры:

/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

Каждая фаза — отдельный файл с инструкциями. Форматы описывают структуру статьи. Конфиги содержат специфику каждого сайта.

Вторая итерация: 5 фаз

Расписал пайплайн:

1. Questions — задать вопросы пользователю о теме, аудитории, формате и целевом сайте
2. Research — собрать материал через Exa AI (semantic search) и веб-поиск
3. Draft — написать черновик в выбранном формате
4. Critics — запустить 4 параллельных критика, собрать фидбек, применить правки
5. Deploy — сохранить в нужную директорию, отправить превью в Telegram

Четвёртая фаза отличается от остальных. Вместо одного редактора — 4 специализированных агента работают одновременно:

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

AI Slop Detector ищет клише (“dive into”, “it’s worth noting”). Rhythm Analyzer проверяет flow и варьирование длины предложений. Specificity Checker заменяет расплывчатые фразы конкретными примерами. Fact Checker требует доказательства для утверждений.

Все четверо смотрят на один текст параллельно. Потом собираю их фидбек и вношу правки одним проходом. Если два критика противоречат друг другу — разбираю вручную.

Третья итерация: конфиги сайтов

Создал конфиги для трёх сайтов в 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

Один скилл читает конфиг и понимает, куда сохранять и как уведомлять.

Развороты

Проблема 1: дубликаты скиллов

Когда запустил новый скилл, обнаружил две команды /blogpost в списке:

• Старый скилл (4-pass approach)
• Новый скилл (5-phase pipeline)

Путаница. Удалил старый:

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

Проблема 2: content-factory тоже дубликат

Оказалось, что content-factory — старая версия похожего функционала. Удалил и его. После этого список скиллов стал чистым.

Проблема 3: скилл не задавал вопросы

Первая версия сразу начинала писать, пропуская фазу вопросов. В итоге статья получалась без контекста — 2000 слов общих фраз вроде “AI — мощный инструмент”.

Добавил в начало SKILL.md:

## 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.

Теперь скилл всегда начинает с диалога. Первые 2-3 минуты — вопросы, потом готовый результат с первой попытки.

Результат

В итоге получилась рабочая система:

• 5-фазный пайплайн — от вопросов до деплоя
• Модульность — форматы и конфиги переиспользуются
• Симлинки — один скилл в ~/.claude/skills/blogpost-pipeline/, симлинки в каждом проекте
• Чистота — никаких дубликатов
• Обязательные вопросы — скилл не пишет вслепую

Запускаю /blogpost, отвечаю на 3-4 вопроса, получаю статью в нужном формате для нужного сайта.

Вывод

Параллельные критики — это fan-out/fan-in для текста.

Классический подход к редактированию последователен: черновик → структура → стиль → факты → финальная полировка. Каждый проход ждёт предыдущий.

Новый подход: черновик → [4 агента одновременно] → одно объединённое исправление. Быстрее и тщательнее, потому что агенты не влияют друг на друга и не пропускают проблемы, которые “уже исправил предыдущий”.

Когда я запустил четырёх критиков на этом черновике, они нашли:

• 7 мест с hedging-словами (“возможно”, “типа”)
• 3 монотонных списка с одинаковой длиной пунктов
• 5 абстрактных утверждений без примеров
• 2 технические неточности

Вручную я бы потратил 30-40 минут на 4 прохода. Параллельные агенты сделали это за 2 минуты.

---

Эта статья написана скиллом, который в ней описан.