linkedin-pipeline-redactor

name

linkedin-pipeline-redactor

description

Redacta drafts de LinkedIn (post + carrusel 9 slides) para {{USER_NAME}} a partir de un payload de noticias seleccionadas (entregado inline por linkedin-pipeline-curator o por mensaje directo del usuario). Activa cuando el usuario diga "redacta drafts pendientes", "procesa estos items", "monta los drafts de LinkedIn", "escribe los posts pendientes", o cuando llegue un payload con items aprobados. Clasifica cada item por tipo (dato_cifra, hot_take, launch, framework_playbook, caso_historia, tendencia_report, plataforma_cambia) y diseña 2-3 preguntas adaptadas via AskUserQuestion. Recoge takes/anclajes/CTA, redacta cada draft en voz {{USER_NAME}} ({{USER_ROLE}}, sin emojis, sin AI-writing), construye 9 slides, escribe a OUTPUTS/drafts/{id}.json y refresca el artifact linkedin-content-pipeline (que solo lee del disco).

LinkedIn Pipeline Redactor (v2 — payload inline)

Convierte items aprobados (noticias o ángulos manuales) en drafts completos: post text + carrusel 9 slides en la voz de {{USER_NAME}}. Las preguntas se adaptan al TIPO de item — plantilla fija produce drafts superficiales.

Cambio v2 vs v1: ya no se lee queue.json. El payload llega inline desde la skill linkedin-pipeline-curator o desde el chat directamente. La arquitectura del bridge artifact→chat se eliminó.

---

Step 1 — Recoger el payload

Busca en este orden:

1. Payload inline en el contexto del turno actual. El curator lo pasa con la frase "Procesa estos N items... El payload está inline a continuación: { ... }". Si está, parsea el JSON y úsalo. Es el camino preferente.

2. Payload pasado por el usuario directo. Si el usuario pega un JSON con {approvedAt, items: [...]} en el mensaje, úsalo.

3. (Legacy, solo fallback) Si no hay payload en el contexto, lee OUTPUTS/redaction-requests/queue.json por compatibilidad. Si tampoco existe, di "no hay items pendientes para redactar — invoca primero linkedin-pipeline-curator o pega un payload" y para.

Formato esperado del payload:

{
  "approvedAt": "2026-04-28T08:30:00Z",
  "items": [
    {
      "id": "ai-mkt-3",
      "kind": "news",
      "sectorId": "ai-mkt",
      "sectorTag": "AI/MKT",
      "title": "Andromeda de Meta convierte la creatividad en el driver clave",
      "source": "B2 The 7",
      "date": "2026-04-27",
      "summary": "...",
      "url": "https://...",
      "proposedAngle": "Confirmo full: el pivot..."
    },
    {
      "id": "manual-1",
      "kind": "manual_angle",
      "text": "CAC -62% en {{ANCHOR_CLIENT_PRIMARY}} en 4 meses sin bajar volumen"
    }
  ]
}

Si hay >5 items, antes de empezar a preguntar haz UNA AskUserQuestion: "Has aprobado [N] drafts. ¿Procesamos los [N] ahora o dividimos en 2 semanas (top 3 + top X)?". Si elige dividir, usa los primeros 3 del payload y guarda el resto en memoria con nota "diferidos".

---

Step 2 — Clasificar cada item

Para cada item con kind: "news", asigna uno de estos tipos según title + summary + proposedAngle:

• dato_cifra — Titular con número fuerte como anchor. "78% de ecommerce calcula mal su CAC", "+233% en CAC", "70 USD CPL". El framing está en el dato.
• hot_take — Titular con tesis fuerte u opinión contraria. "X está muerto", "el playbook ya no funciona", "los stocks B2B se hunden porque...".
• launch — Anuncio de producto, feature o integración. "lanza", "introduce", "anuncia", "expande", "integra X con Y".
• framework_playbook — Sistema, lista numerada o método. "3 reglas", "5 señales", "checklist", "framework", "the rule of 3s".
• caso_historia — Historia de empresa/persona específica. "[empresa] consiguió X", "el caso Y", "Powerfleet y TELUS lanzan".
• tendencia_report — Estudio o agregado. "según estudio", "el 67% de", "report 2026".
• plataforma_cambia — Cambio de reglas en plataforma operacional. "Meta retira", "Google actualiza", "Shopify abre", "TikTok modifica algoritmo".

Si una noticia es híbrida, elige el tipo dominante (el que aparece primero en el flow del titular).

Para items con kind: "manual_angle", trátalos como caso_historia por defecto.

---

Step 2.4 — Resumen del artículo + enlace (antes de investigar posiciones)

Por qué este paso existe: {{USER_NAME}} decide mejor si conoce la fuente original, no solo el summary del JSON. Antes de mostrarle posiciones del mercado o preguntarle por su tesis, dale acceso al artículo crudo para que se forme su propia opinión.

Pasos:

1. Lee el artículo original

Usa WebFetch sobre el url del item (siempre presente en el JSON del pool). Si la URL falla o devuelve paywall, usa WebSearch con el titular para encontrar versiones cacheadas o reseñas.

2. Resumen del artículo en chat (formato fijo)

Escribe en el chat ESTO antes de cualquier otra cosa:

**📰 Artículo: [titular completo]**

🔗 **Fuente:** [Source name] · [date] · [link clicable]

📝 **Resumen real (no el del pool):** 4-6 líneas con lo que el artículo dice de verdad.
- Tesis principal del autor
- 2-3 datos o citas que el autor usa para sustentar
- A qué audiencia escribe
- Lo que el autor admite que NO sabe / NO cubre

💬 **Tu ángulo del pool (proposedAngle del JSON):** [pega el proposedAngle, 1-2 líneas]

⏸️  *Léelo si quieres verlo completo. Dime "sigue" cuando quieras que pase a las posiciones del mercado y las preguntas. O dime "ya lo conozco, salta" para acelerar.*

3. Esperar señal de {{USER_NAME}}

NO continúes al Step 2.5 hasta que {{USER_NAME}} diga "sigue", "ok", "salta", "adelante" o equivalente. Dale tiempo a leer si quiere.

Si la WebFetch falla y no puedes resumir el artículo de fuente, sé honesto: "No he podido leer el artículo (paywall / 404). Te dejo el link [URL] y el summary del pool: [summary]. ¿Sigo con investigación de posiciones igualmente?".

Reglas

• El resumen real es del ARTÍCULO, no del proposedAngle. Si el artículo dice algo distinto a lo que el batch resumió, dilo explícitamente: "Ojo — el artículo dice X, el pool resumió Y".
• Mantén el bloque corto. 4-6 líneas en el "Resumen real" + 1-2 en el "Tu ángulo". No te vuelvas un periodista.
• El link es OBLIGATORIO. Es la pieza que le permite a {{USER_NAME}} leer la fuente entera si su intuición le dice que falta contexto.

---

Step 2.5 — Investigación previa OBLIGATORIA (antes de preguntar)

Por qué este paso existe: sin contexto, las preguntas son a ciegas. {{USER_NAME}} puede elegir una tesis sin saber si ya está siendo defendida por 50 personas en LinkedIn esa misma semana, o si hay un ángulo que NADIE está cubriendo. El objetivo es darle el panorama antes de pedirle posición.

Antes de diseñar las 4 preguntas (Step 3), HAZ ESTO:

1. WebSearch del tema (1-2 búsquedas)

Busca el titular o keywords clave de la noticia para ver:

• Qué dicen los analistas y blogs especializados
• Qué posiciones circulan en LinkedIn / Twitter / Substack
• Qué dicen los competidores del producto/empresa de la noticia
• Cifras o datos recientes que matizan o desafían el ángulo del pool

Limita a 1-2 WebSearch — no es deep research. Solo lo justo para mapear el panorama.

2. Resumen al chat antes de preguntar (4-6 líneas)

Tras la búsqueda, escribe en el chat un bloque ESTRUCTURADO así:

**Investigación previa: [titular corto]**

📰 **Lo que dice la noticia:** [1 frase con la tesis principal]
📰 **Lo que NO dice (ángulo del pool):** [proposedAngle del JSON, 1 línea]

🌐 **Posiciones que circulan en el mercado esta semana:**
1. [Posición A] — defendida por [tipo de player: analistas / agencias / vendor / competidor]
2. [Posición B] — defendida por [...]
3. [Posición C] — defendida por [...]
(opcional 4)

🎯 **Hueco identificado:** [qué nadie está diciendo todavía, máximo 2 frases — esto es el insight más valioso]

💡 **Mi recomendación de tesis:** [tu sugerencia de ángulo, basada en lo que cuadra con la voz de {{USER_NAME}}, sus clientes y el hueco]

3. Preguntas informadas

Solo DESPUÉS del bloque de investigación, lanza el AskUserQuestion con las 4 preguntas (Step 3). Las opciones de Q1 (tesis) ahora están INFORMADAS por la investigación: cada una representa una posición real que circula + tu recomendación + opciones de matiz.

Reglas

• Si la búsqueda no devuelve nada nuevo (tema saturado o muy específico), dilo en el resumen ("Posiciones uniformes — el sector está alineado en X. El hueco está en Y") y propón con más confianza tu tesis recomendada.
• Si encuentras una contradicción importante (ej. cifra del pool refutada por estudio reciente), márcala con ⚠️ en el resumen para que {{USER_NAME}} lo vea antes de elegir.
• No copies los WebSearch results literal — sintetiza posiciones, no resúmenes de articles.
• El tiempo invertido aquí es 2-3 minutos extra por noticia. Vale la pena.

---

Step 3 — Diseñar preguntas adaptadas al tipo (profundas, no superficiales)

Principio crítico: Las preguntas NO son para confirmar lo obvio. Son para extraer la opinión real, el ángulo no obvio y la evidencia propia que solo {{USER_NAME}} tiene. Si las opciones cerradas son "Confirmo / Contra / Matiz", produces drafts blandos y genéricos.

Reglas de diseño:

1. Lee el proposedAngle del pool ANTES de diseñar las preguntas. Eso es el draft de tesis. Tus preguntas deben empujar a {{USER_NAME}} a refinarlo o desafiarlo, no a aceptarlo.

2. 4 preguntas por noticia, no 3. La cuarta es la que saca el insight no obvio.

3. Cada pregunta tiene 4 opciones HIPÓTESIS específicas + Other. Las opciones NO son "Confirmo / Contra / Matiz" abstractas. Son tesis concretas con cifra/cliente/mecánica que se podrían defender. Ejemplo malo: "Confirmo full". Ejemplo bueno: "Confirmo: en {{ANCHOR_CLIENT_PRIMARY}} lo medí en X% de campañas y el patrón aguantó N meses".

4. Al menos 1 pregunta espera "Other" con texto libre. Diséñala así: las 4 opciones cerradas son "buenas pero genéricas", y Other es la apuesta por la respuesta más específica. Indica esto en la descripción de Other: "(escribe tu insight propio aquí — esta pregunta es para sacarte la perspectiva única que el resto no tiene)".

5. NUNCA preguntes "¿qué CTA?" como pregunta independiente. El CTA depende de la tesis. Lo derivas en Step 5 a partir del take + audiencia + cliente diana. Si necesitas confirmarlo, hazlo dentro de la Q4.

Estructura de las 4 preguntas

Q1 — La PROVOCACIÓN (fuerza posición)

No "Confirmo / Contra". Cuatro tesis posibles MUY distintas entre sí, cada una con anclaje implícito. Ejemplo para una noticia de "Adobe lanza agents":

• "El problema no es Adobe, es el workflow viejo debajo del agente — vi 3% adoption en CRMs heredados"
• "Adobe llega tarde — Salesforce y HubSpot ya tienen mejor agent en producción 6 meses"
• "Lo que importa no es el agente, es la API que expone — sin acceso al data layer es un chatbot bonito"
• "Es marketing puro: agentic == funnel para vender Firefly y suite cara, no un cambio operacional"

Esas son 4 posiciones SUSTANTIVAS y EXCLUYENTES. {{USER_NAME}} elige la suya o escribe "Other" con la suya. Cualquiera de las 4 produce un post diferente.

Q2 — La EVIDENCIA propia (obligar a anclar con dato)

No "¿qué cliente?". Cuatro evidencias específicas que {{USER_NAME}} podría tener, con cifras propuestas que él valida o ajusta.

• "{{ANCHOR_CLIENT_HISTORICAL}} 2022: probamos X y vimos Y% en N días"
• "{{ANCHOR_CLIENT_CURRENT}} ahora mismo: medí Z y el patrón es W"
• "Cliente fintech anónimo: 1.380 EUR de CAC, 4.200 EUR de LTV, payback 11 meses"
• "Agregado de mi consultoría: el 60% del trabajo de mes 1 es positioning, no growth"
• Other: "(tienes una cifra mejor — escríbela)"

Las cifras propuestas tienen que sonar a {{USER_NAME}}, basadas en la memoria de los clientes ancla. Si no estás seguro de la cifra, marca con "[verifica]" en la opción.

Q3 — Lo que NADIE más está diciendo (Other esperado)

Esta es la pregunta clave. La diseñas para que NINGUNA opción cerrada sea suficiente — todas son "puntos de entrada" pero la respuesta buena es texto libre en Other. Las descripciones de las 4 opciones DEBEN decir explícitamente que escribir en Other es la opción premium.

Ejemplo: "¿Qué insight ves en este tema que NADIE en LinkedIn está contando ahora mismo?"

• Opción A: "Escribe en Other tu insight más afilado — esta pregunta es para sacar tu perspectiva única, no la opinión de manual" (← sí, opción A invita a Other)
• Opción B: "El tema está saturado, no hay nada nuevo que decir (skip esta noticia)"
• Opción C: "Hay un sub-aspecto técnico que el sector ignora — describe en Other cuál"
• Opción D: "Hay un caso límite donde la tesis dominante rompe — describe en Other"

Si {{USER_NAME}} elige cualquier opción que apunte a Other, capturas su texto literal. Eso es ORO para el draft.

Q4 — Aplicación + audiencia diana

Mezcla CTA con audiencia:

• "Founder/CEO B2B SaaS: terminar con DM filtrado a quien tenga el dato concreto"
• "CMO de marca >5M revenue: terminar con pregunta provocadora a comentarios"
• "Growth marketer junior: terminar con regla de bolsillo para llevarse"
• "Mixto sector: terminar con pregunta abierta sin sub-segmentar"
• Other: "(otra audiencia o cierre específico)"

Plantillas POR TIPO (las anteriores siguen disponibles como esqueleto, pero adapta SIEMPRE al titular concreto)

Si la noticia es dato_cifra: Q1 = 4 hipótesis de por qué la cifra es engañosa o real, Q2 = anclaje, Q3 = insight no obvio, Q4 = audiencia.

Si hot_take: Q1 = 4 contra-tesis, Q2 = evidencia, Q3 = trampa que nadie ve, Q4 = audiencia.

Si launch: Q1 = 4 framings (early adopter, escéptico técnico, comparativa con alternativa, marketing puro), Q2 = caso de uso real o alternativa que ya usa, Q3 = qué condición tendría que cumplirse para que el lanzamiento valiera la pena, Q4 = audiencia.

Si framework_playbook: Q1 = adoptar / adaptar / rechazar / añadir paso, Q2 = versión propia con métrica de validación, Q3 = el paso que NO está en el framework y debería estar, Q4 = audiencia.

Si caso_historia: Q1 = paralelo / opuesto / aprendizaje sectorial / contraejemplo, Q2 = cliente o proyecto propio que aplica, Q3 = qué del caso NO se cuenta, Q4 = audiencia.

Si tendencia_report: Q1 = confirmo, contradigo, segmento, sesgo del estudio, Q2 = mi data interna, Q3 = la implicación que la prensa ignora, Q4 = audiencia.

Si plataforma_cambia: Q1 = acción urgente / esperar / sub-segmento dañado / oportunidad escondida, Q2 = cliente afectado, Q3 = workaround propio, Q4 = audiencia.

Items híbridos

Q1 del tipo dominante, Q2 del secundario, Q3 siempre de "lo que nadie dice", Q4 audiencia.

Reglas de calidad antes de lanzar AskUserQuestion

Antes de mandar las preguntas, valida internamente:

• ¿Las opciones de Q1 son 4 tesis específicas con anclaje implícito? (no "Confirmo / Contra")
• ¿Q2 propone 4 cifras concretas para que {{USER_NAME}} valide o ajuste? (no "¿qué cliente?")
• ¿Q3 está diseñada para que la mejor respuesta sea Other libre?
• ¿Q4 mezcla audiencia + cierre, no solo CTA genérico?

Si alguna falla, rediseña esa pregunta.

---

Step 4 — Recoger respuestas

Para cada item, llama a AskUserQuestion con tus preguntas adaptadas. Espera. Acumula {itemId: {q1, q2, q3, ...}} en memoria del turno.

• Si el usuario contesta "Other", captura el free text — es oro, es su voz literal.
• Si el usuario salta una pregunta o contesta vago, NO insistas — usa lo que tienes.

---

Step 5 — Redactar cada draft

Voz de {{USER_NAME}}

{{USER_BIO}}

Esta sección la rellena el bootstrap durante la instalación. El bootstrap genera USER_BIO desde:

• ABOUT-ME/about-me.md (si existe en el folder padre del pipeline)
• ABOUT-ME/my-company.md (si existe)
• O preguntas vía AskUserQuestion si no hay ABOUT-ME.

Formato esperado del USER_BIO: "[N años en X], [ex-rol Y en empresa-emblemática]. Ha trabajado con {{ANCHOR_CLIENTS_HISTORICAL}}. Hoy [rol-actual] de [empresa-actual] con [N] clientes activos: {{ANCHOR_CLIENTS_CURRENT}}."

Tono: directo, datos primero, sin marketing speak, sin emojis, sin corporate.

Reglas anti-AI-writing (críticas)

NO uses estos patrones (matan la credibilidad):

• "delve", "dive into", "navigate", "leverage", "elevate", "unleash", "unlock"
• "in conclusion", "the truth is", "let's dive in", "imagine if"
• "it's not just X, it's Y" (estructura overused)
• Listas con todo en negrita o con emojis al inicio
• "✨", "🚀", "💡" o cualquier emoji
• Frases ascensionales tipo "transforming the way we..."

SÍ usa:

• Frases cortas, párrafos de 1-3 líneas separados por línea en blanco
• Cifras concretas con contexto
• "Esto es lo que vi en [cliente]" en lugar de "studies show"
• Tono primera persona, declarativo
• Hooks con un dato específico, no genéricos
• MAYÚSCULAS como martillo (1 vez por pieza, sobre la palabra-tesis)
• Asteriscos de censura ocasionales (jder, cojnudo) si hay carga emocional

Estructura del post (800-1500 chars)

1. Hook (1-3 líneas, dato fuerte o claim)
2. Setup (problema o tendencia)
3. Caso/cifra (lo que viviste o el caso real)
4. Framework/lección (regla práctica)
5. Aplicación (cómo verla mañana)
6. CTA (según user input)

Adaptación según take:

• "Confirmo" → Hook con dato → Setup → Cifra propia → Framework → Aplicación → CTA
• "Contra" → Hook con tesis original → "Pero..." → Tu argumento → Cifra/caso → Framework → CTA
• "Matiz" → Hook → "Cuándo aplica X, cuándo no Y" → Cifras de cada lado → Framework → CTA

Estructura del carrusel (9 slides)

• Slide 1 — cover: {type:"cover", title: titular del post, sub: subtítulo 8-12 palabras}
• Slides 2-8 — body: {type:"body", title: headline corto, text: 2-4 líneas, máx 25 palabras por línea}
• Slide 9 — cta: {type:"cta", title: pregunta directa, text: invitación a comentar/DM}

Cada body slide cubre un punto del post. Si hay <7 puntos en el post, usa menos slides (mín 5: cover + 3 body + cta).

Fechas y horas

Cadencia estándar: {{CADENCE}}.

Si hay >3 drafts, propón viernes 10:00 y siguiente lunes 09:00, pero confirma antes de exceder 3/semana.

Calcula fechas a partir de "hoy" — si hoy es sábado o domingo, los drafts arrancan el martes próximo. Si hoy es martes, el primer draft puede ser hoy mismo si hay tiempo (>2h antes de las 09:30) o mañana miércoles. Resuelve la fecha actual con bash: date '+%Y-%m-%d %A'.

Cifras inventadas

Si user dejó "Anclaje real" vacío y no tienes una cifra de los archivos de {{USER_NAME}} ({{ANCHOR_CLIENTS}}), marca con [verifica cifra] cualquier número.

NUNCA inventes cifras de clientes sin marcarlas. Es la regla más importante.

---

Step 6 — Escribir los drafts a disco

Para cada draft, escribe a: {MOUNT}/{{FOLDER_NAME}}/OUTPUTS/drafts/{id}.json

Donde {MOUNT} se resuelve con MNT=$(ls -d /sessions/*/mnt 2>/dev/null | head -1).

ID del draft: d-YYYY-MM-DD-N donde N empieza en 1 para el batch del día. Si hoy ya hay drafts d-2026-04-29-1 y d-2026-04-29-2, el siguiente es d-2026-04-29-3.

Estructura JSON:

{
  "id": "d-2026-04-29-1",
  "sourceItemId": "ai-mkt-3",
  "title": "Título del post (igual al hook abreviado)",
  "hook": "Primera línea del post",
  "day": "Martes",
  "time": "09:30",
  "date": "2026-05-05",
  "postText": "Texto completo del post listo para copy-paste a LinkedIn",
  "userTake": "Confirmo",
  "userAnclaje": "{{ANCHOR_CLIENT_PRIMARY}}",
  "cta": "Comentar",
  "slides": [
    {"type": "cover", "title": "...", "sub": "..."},
    {"type": "body", "title": "...", "text": "..."},
    ...
    {"type": "cta", "title": "...", "text": "..."}
  ],
  "createdAt": "2026-04-29T09:00:00Z",
  "approved": false,
  "published": false,
  "slug": "creativo-vs-targeting"
}

Sobre el slug: alias corto y memorable para que {{USER_NAME}} pueda referirse al draft en chat sin teclear el ID feo. Genera 2-4 palabras kebab-case que capturen la idea central del post. Ejemplos: atribucion-meta, h1-positioning, nrr-saas, tiktok-pay-to-play. Reglas:

• Lowercase, palabras separadas por guiones, sin acentos ni eñes
• Máximo 30 caracteres
• Único entre los drafts existentes — si ya existe ese slug, añade sufijo -2, -3 etc.
• Lo derivas del title o del userTake/userAnclaje, lo que sea más memorable

REGLAS DE ESTADO (críticas):

• approved: false SIEMPRE en drafts recién redactados. {{USER_NAME}} debe aprobar explícitamente cada draft con "aprueba d-XXX" antes de que el publisher (scheduled task publish-due-drafts 8:00am) los suba a Metricool. Nunca pongas approved: true automáticamente.
• published: false SIEMPRE inicial. Solo el publisher cambia este flag a true después de subirlo a Metricool con éxito.
• date y time opcionales pero recomendados. Si {{USER_NAME}} no quiere programar todavía (caso "déjame esto en backlog"), pon date: null (o omite el campo). El draft entonces aparece en la sección "Backlog · drafts sin programar" del artifact.

Crea la carpeta si no existe (mkdir -p).

---

Step 7 — Regenerar el artifact unificado (Pool + Calendario)

Cambio v4: el artifact linkedin-content-pipeline es ahora UNIFICADO con dos pestañas (Pool de noticias + Calendario editorial). El builder Python lee SIEMPRE ambas carpetas (OUTPUTS/news/ y OUTPUTS/drafts/) y genera un HTML único con datos embebidos. Cuando escribas drafts nuevos, regenera ese artifact único.

Pasos exactos:

1. Ejecuta el script Python builder vía bash:

MNT=$(ls -d /sessions/*/mnt 2>/dev/null | head -1)
SCRIPT="$MNT/{{FOLDER_NAME}}/OUTPUTS/_internal/scripts/build_artifact_html.py"
OUT_HTML="$MNT/{{FOLDER_NAME}}/OUTPUTS/_internal/built/pipeline.html"
python3 "$SCRIPT" "$OUT_HTML"

El script lee TODOS los drafts en OUTPUTS/drafts/*.json + los news JSONs existentes y produce un HTML standalone con datos embebidos. Los news del Pool se preservan automáticamente porque el builder los relee.

2. Llama mcp__cowork__update_artifact con:

• id: linkedin-content-pipeline
• update_summary: +N drafts redactados [fecha]
• html_path: /Users/alfonsosb/PROJECTS/Cowork/curso-claude/demo-curso-vacio/PROJECTS/{{FOLDER_NAME}}/OUTPUTS/_internal/built/pipeline.html
• mcp_tools: []

Si el script falla (no existe, error Python), no bloquea — los drafts ya están escritos. Reporta el error en el resumen final del Step 8 y dile al usuario que regenere manualmente con "actualiza el pipeline".

---

Step 8 — Resumir al usuario

Listos [N] drafts:
- d-2026-04-29-1 [titular corto] · {{CADENCE_PRIMARY}}
- d-2026-04-29-2 [titular corto] · miércoles 08:45
- d-2026-04-29-3 [titular corto] · jueves 09:15

Pulsa Refrescar en el artifact para verlos en el calendario.

Si has marcado cifras con [verifica cifra] en algún draft, lístalas:

Cifras a verificar antes de publicar:
- d-2026-04-29-1: "CAC bajó 31% en {{ANCHOR_CLIENT_PRIMARY}}" → confirma o ajusta
- d-2026-04-29-2: "20 reviews en 7 días en {{ANCHOR_CLIENT_CURRENT}}" → confirma o ajusta

---

Reglas finales

• No inventes cifras sin marcar [verifica cifra]. La credibilidad de {{USER_NAME}} depende.
• No emojis en post text ni en slides.
• No los AI-writing tells listados arriba.
• Cada draft suena como {{USER_NAME}} despierto a las 7am pensando en LinkedIn — no community manager.
• Si una respuesta del usuario es ambigua o falta, no preguntes de nuevo. Usa el mejor proxy y deja nota en userTake o userAnclaje indicando que es default.
• Si el user marca >5 items en el payload, ofrece dividir en 2 batches antes de empezar.
• No escribas a queue.json. La cola es del pasado.
• Si llamas al artifact update y falla, no es bloqueante — el usuario refresca.