Cómo monté un pipeline para posts con críticos en paralelo

Intención

Quería mejorar mi skill de escritura de posts. Me inspiré en un artículo sobre content pipeline — ahí se usa el formato de “documentación de conversaciones”, donde el autor muestra no solo el resultado, sino el proceso. No quería copiarlo, quería crear un sistema modular:

• Pipeline de 5 fases con orquestación de agentes
• Integración con Exa AI para investigación
• Dos formatos de artículo (estándar y conversacional)
• Posibilidad de reutilizar la skill en diferentes sitios

La idea principal: en lugar de passes de edición secuenciales, lanzar agentes especializados en paralelo. Como el patrón fan-out/fan-in en sistemas distribuidos — distribuyo el trabajo, recopilo los resultados.

Intentos

Primera iteración: estructura

Empecé creando una estructura modular:

/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

Cada fase es un archivo separado con instrucciones. Los formatos describen la estructura del artículo. Los configs contienen los detalles específicos de cada sitio.

Segunda iteración: 5 fases

Diseñé el pipeline:

1. Questions — hacer preguntas al usuario sobre el tema, la audiencia, el formato y el sitio destino
2. Research — recopilar material a través de Exa AI (búsqueda semántica) y búsqueda web
3. Draft — escribir el borrador en el formato elegido
4. Critics — lanzar 4 críticos en paralelo, recopilar feedback, aplicar correcciones
5. Deploy — guardar en el directorio correcto, enviar preview por Telegram

La cuarta fase es diferente a las demás. En vez de un editor — 4 agentes especializados trabajan simultáneamente:

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

El AI Slop Detector busca clichés (“dive into”, “it’s worth noting”). El Rhythm Analyzer verifica el flujo y la variación en la longitud de las frases. El Specificity Checker reemplaza frases vagas por ejemplos concretos. El Fact Checker exige evidencia para las afirmaciones.

Los cuatro miran el mismo texto en paralelo. Luego junto su feedback y aplico las correcciones en un solo pase. Si dos críticos se contradicen — lo resuelvo manualmente.

Tercera iteración: configs de los sitios

Creé configs para tres sitios en 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

Una skill lee el config y sabe dónde guardar y cómo notificar.

Giros inesperados

Problema 1: skills duplicadas

Cuando lancé la nueva skill, aparecieron dos comandos /blogpost en la lista:

• Skill antigua (enfoque de 4 passes)
• Nueva skill (pipeline de 5 fases)

Confusión. Borré la antigua:

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

Problema 2: content-factory también era un duplicado

Resultó que content-factory era una versión antigua de funcionalidad similar. La borré también. Después de eso, la lista de skills quedó limpia.

Problema 3: la skill no hacía preguntas

La primera versión empezaba a escribir de inmediato, saltándose la fase de preguntas. El artículo resultante salía sin contexto — 2000 palabras de frases genéricas como “la IA es una herramienta poderosa”.

Añadí al inicio del 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.

Ahora la skill siempre empieza con un diálogo. Los primeros 2-3 minutos son preguntas, y luego el resultado listo desde el primer intento.

Resultado

Al final quedó un sistema funcional:

• Pipeline de 5 fases — de preguntas hasta el deploy
• Modularidad — formatos y configs se reutilizan
• Symlinks — una skill en ~/.claude/skills/blogpost-pipeline/, symlinks en cada proyecto
• Limpieza — sin duplicados
• Preguntas obligatorias — la skill no escribe a ciegas

Lanzo /blogpost, respondo 3-4 preguntas, obtengo el artículo en el formato correcto para el sitio correcto.

Conclusión

Los críticos en paralelo son fan-out/fan-in para texto.

El enfoque clásico de edición es secuencial: borrador → estructura → estilo → hechos → pulido final. Cada pase espera al anterior.

Nuevo enfoque: borrador → [4 agentes simultáneos] → una corrección unificada. Más rápido y más completo, porque los agentes no se influyen entre sí y no pasan por alto problemas que “el anterior ya corrigió”.

Cuando lancé los cuatro críticos sobre este borrador, encontraron:

• 7 lugares con palabras de hedging (“quizás”, “tipo”)
• 3 listas monótonas con ítems de igual longitud
• 5 afirmaciones abstractas sin ejemplos
• 2 imprecisiones técnicas

Manualmente habría tardado 30-40 minutos en 4 passes. Los agentes en paralelo lo hicieron en 2 minutos.

---

Este artículo fue escrito por la skill que describe.