Redactor de Boletines

¿Qué hace Redactor de Boletines?

Redacta correos electrónicos de actualización de producto y boletines de anuncio de funcionalidades. Maneja líneas de asunto, texto de vista previa, estructura del correo y contenido apropiado para la audiencia.

Resolución de Entrada

Resuelve el argumento (si se proporciona) en este orden:

1. Ruta a un brief de marketing existente (.md que contenga "Resumen Ejecutivo" o "Mensajes Clave") -> brief de marketing
2. Ruta a un blog post existente (.md con estructura de blog post) -> blog post
3. Ruta a un changelog existente (.md con secciones Añadido/Corregido/Cambiado o CHANGELOG.md) -> changelog
4. Coincide con URL de GitHub o patrón #\d+ -> PR
5. Contiene ... o .. -> rango de refs git
6. Resuelve a archivo/directorio existente -> funcionalidad del código base
7. De lo contrario -> texto libre

Si no se proporciona ningún argumento, pregunta: "¿Qué debería cubrir el boletín? Puedes proporcionar un brief de marketing, un blog post, un changelog, una URL/número de PR, un rango de refs git, una ruta de archivo/directorio, o simplemente describir la actualización."

Si múltiples interpretaciones coinciden, confirma con el usuario.

Flujo del Proceso

digraph newsletter {
    rankdir=TB;
    "Resolver entrada" [shape=box];
    "Fase 1: Descubrimiento" [shape=box];
    "Fase 2: Configuración" [shape=box];
    "Fase 3: Redacción" [shape=box];
    "Fase 4: Revisión" [shape=box];
    "¿Aprobado?" [shape=diamond];
    "Fase 5: Salida" [shape=box];

    "Resolver entrada" -> "Fase 1: Descubrimiento";
    "Fase 1: Descubrimiento" -> "Fase 2: Configuración";
    "Fase 2: Configuración" -> "Fase 3: Redacción";
    "Fase 3: Redacción" -> "Fase 4: Revisión";
    "Fase 4: Revisión" -> "¿Aprobado?";
    "¿Aprobado?" -> "Fase 3: Redacción" [label="revisiones"];
    "¿Aprobado?" -> "Fase 5: Salida" [label="sí"];
}

NO omitas fases. Haz preguntas a un ritmo natural. Si el usuario responde varias preguntas a la vez, acepta las respuestas agrupadas y salta adelante.

Si el usuario dice "elige los valores por defecto", "tú decides" o similar, elige valores predeterminados razonables según el contexto, indica lo que elegiste y pide una sola confirmación antes de continuar.

Nunca asumas sin confirmar.

Fase 1: Descubrimiento

Paso 1 - Analizar la entrada

Tipo de entrada	Qué leer
Brief de marketing	Extraer declaración del problema, propuesta de valor, audiencia, mensajes clave. Saltar al Paso 3. Aún así, hacer Paso 2 si el brief carece de contexto del producto.
Blog post	Extraer titular, puntos clave, audiencia, CTA. Saltar al Paso 3. Aún así, hacer Paso 2 si carece de contexto del producto.
Changelog	Extraer todas las entradas. Usar como base para un correo resumen. Saltar al Paso 3.
PR	Diff, descripción del PR, comentarios de revisión, mensajes de commit (gh pr view, gh pr diff). Para PRs grandes (20+ archivos), enfocarse en cambios visibles para el usuario.
Refs git	git diff y git log entre refs. Para rangos grandes, priorizar mensajes de commit y cambios visibles para el usuario.
Funcionalidad del código base	Leer los archivos/directorios especificados.
Texto libre	Analizar la descripción del usuario. Si le faltan detalles, preguntar al usuario que proporcione más información o que señale un archivo/PR específico. Recurrir a preguntas abiertas solo si no puede.

Cambios visibles para el usuario incluyen: nuevas funcionalidades, cambios de UI, cambios de API, mejoras de rendimiento, correcciones de errores y actualizaciones de documentación. Cambios internos incluyen: refactorizaciones, adiciones de pruebas, cambios de CI y actualizaciones de dependencias. Cuando tengas dudas, enumera lo que encontraste y pregunta al usuario cuáles son relevantes.

Manejo de errores:

• gh no disponible -> informar al usuario, sugerir gh auth login, ofrecer entrada alternativa
• PR/ref inválido -> pedir al usuario que verifique
• Archivo no encontrado -> pedir la ruta correcta

Paso 2 - Leer contexto más amplio del producto

Leer si existen: README, docs/, package.json (o equivalente).

Si no se encuentra nada, preguntar: "No pude encontrar contexto del producto en el repositorio. ¿Puedes describir brevemente el producto y para quién es?"

Paso 3 - Presentar entendimiento y determinar formato

Presentar un resumen estructurado:

"Aquí está lo que usaré como base para el boletín:"

• Actualización A - descripción breve
• Actualización B - descripción breve

"¿Algo que añadir, eliminar o corregir?"

Luego determinar el formato del correo según el número de actualizaciones:

• Actualización única importante -> correo de una sola funcionalidad (enfocado, profundo)
• Múltiples actualizaciones -> correo resumen (lista priorizada, la más importante expandida)

Confirmar el formato con el usuario.

Si no se encuentran cambios visibles para el usuario en la entrada, informar al usuario y detenerse: "No se encontraron cambios visibles para el usuario en esta entrada. No hay nada sobre lo que escribir un boletín."

NO continuar hasta que el usuario confirme el alcance y el formato.

Fase 2: Configuración

Hacer estas preguntas:

P1 - Audiencia: "¿A quién va dirigido este correo?" (todos los usuarios, usuarios avanzados, nuevos usuarios, nivel de plan específico, desarrolladores, usuarios no técnicos, otro)

P2 - Formato de salida: "¿En qué formato quieres el correo?"

• Solo texto - línea de asunto, texto de vista previa, cuerpo del texto, texto del CTA (para pegar en tu herramienta de correo)
• Markdown - markdown formateado que la mayoría de herramientas de correo pueden importar

P3 - Tono: Leer contenido existente del repositorio (README, docs, blog posts) para detectar la voz del producto. Luego confirmar:

"Según tu contenido existente, el tono parece [p. ej., conversacional y amigable para desarrolladores]. ¿Debo mantenerlo o ir en otra dirección?"

Si no hay contenido existente para analizar, preguntar directamente qué tono quiere el usuario.

P4 - CTA: Inferir la llamada a la acción más apropiada del contexto:

• Nueva funcionalidad -> "Pruébalo ahora", "Descubre lo nuevo"
• Mejora -> "Compruébalo", "Ve la diferencia"
• Código abierto -> "Actualiza ahora", "Mira el lanzamiento"

"Sugiero que el CTA sea: [CTA inferido]. ¿Quieres ese o uno diferente?"

Fase 3: Redacción

Líneas de asunto

Generar 3-5 opciones de línea de asunto con diferentes enfoques:

• Basado en beneficio ("Tus informes ahora se exportan a PDF")
• Curiosidad ("Reconstruimos cómo funciona la búsqueda")
• Nombre de funcionalidad específica ("Presentamos el modo oscuro")
• Pregunta ("¿Aún esperando que terminen las exportaciones?")
• Urgencia/oportunidad ("Nuevo esta semana: 3 funcionalidades que pediste")

Recomendar una y explicar por qué funciona mejor. También explicar las ventajas y desventajas de las otras.

Reglas:

• 30-50 caracteres óptimo (evitar truncamiento en móvil)
• Ser específico, no genérico ("Nuevo: Exportaciones a PDF" gana a "Actualización de Producto - Marzo 2026")
• Sin palabras de spam (Gratis, Compra Ahora, Actúa Ahora)

Texto de vista previa

Generar texto de vista previa para cada opción de línea de asunto. El texto de vista previa es la línea secundaria visible en las vistas previas de la bandeja de entrada.

Reglas:

• 40-130 caracteres
• Ampliar la línea de asunto, no repetirla
• Incluir el beneficio o resultado clave

Cuerpo del correo

Estructura para correo de una sola funcionalidad:

1. Declaración del problema - una frase describiendo el punto débil que resuelve
2. Qué cambió - 2-3 frases describiendo la actualización en lenguaje de beneficio para el usuario ("Los informes cargan más rápido" no "Ejecución de consulta SQL optimizada")
3. Marcador visual - <!-- TODO: Añadir captura de pantalla o GIF mostrando la funcionalidad en acción --> con una descripción de qué capturar
4. Botón CTA - una sola acción clara

Estructura para correo resumen:

1. Actualización principal - la actualización más importante recibe el tratamiento completo de una sola funcionalidad (problema, qué cambió, visual, CTA)
2. Actualizaciones secundarias - viñetas breves con descripciones de una línea y enlaces
3. Correcciones rápidas / mejoras - lista agrupada de cambios más pequeños
4. CTA de cierre - una sola acción o "Ver todas las actualizaciones"

Reglas de redacción

• Empezar con el beneficio para el usuario, no con lo que construiste
• Tono conversacional, no corporativo
• Párrafos cortos (máximo 2-3 frases)
• Una idea por párrafo
• Nunca uses guiones largos en el contenido generado. Sin caracteres "---". Usa comas, dos puntos, puntos o paréntesis en su lugar.
• Sin jerga. "Los informes cargan más rápido" gana a "Plan de ejecución de consulta SQL optimizado"
• Negrita para frases clave que faciliten el escaneo
• Manténlo escaneable. Más corto es mejor. Si el correo toma más de 60 segundos de lectura, es demasiado largo.

Variantes por segmento

Después de generar el correo principal, preguntar:

"¿Quieres que genere variantes para diferentes segmentos de audiencia? (p. ej., una versión más técnica para desarrolladores, una versión más simple para usuarios no técnicos)"

Si la respuesta es sí, generar las variantes solicitadas, ajustando tono, profundidad y énfasis de funcionalidad por segmento.

Fase 4: Revisión

Presentar el correo completo:

"Aquí está el boletín:"

Opciones de línea de asunto: (con recomendación y texto de vista previa para cada una)

1. Asunto: "..." / Vista previa: "..."
2. Asunto: "..." / Vista previa: "..."
3. Asunto: "..." / Vista previa: "..."

Cuerpo: [contenido completo del correo]

"Elige una línea de asunto y dime si quieres algún cambio."

Esperar a que el usuario seleccione una línea de asunto y apruebe o solicite revisiones. Solo proceder a la salida una vez aprobado.

Fase 5: Salida

Siempre imprimir el correo final aprobado en la terminal.

Luego preguntar: "¿Quieres que guarde esto en emails/<slug>.md? ¿O en una ruta diferente?"

Crear el directorio si no existe. Si el archivo ya existe, preguntar si sobrescribir o crear una copia versionada.

Manejo de Errores

• gh no disponible -> informar al usuario, ofrecer entrada alternativa
• PR/ref inválido -> pedir al usuario que verifique
• Sin contexto del producto -> pedir al usuario que describa el producto
• Sin directorio de correos existente -> usar por defecto emails/, crearlo

Qué NO hace esta habilidad

• Enviar o programar correos
• Gestionar listas de suscriptores o lógica de segmentación
• Crear plantillas de correo o sistemas de diseño
• Generar blog posts o contenido para redes sociales (usa /blog-post o /social-copy)