¿Qué hace Escritor de Publicaciones de Blog?
Escribe publicaciones de blog de alta calidad a partir de cambios de código, briefs de marketing o descripciones de características. Maneja SEO, estructura, coincidencia de tono y contenido visual.
Regla de escritura (no negociable): nunca uses guiones largos (— o –). Usa un guion - en su lugar. Aplica a cada línea del texto generado.
Resolución de Entrada
Resuelve el argumento (si se proporciona) en este orden:
- Ruta a un archivo existente de brief de marketing (
.mdque contenga "Resumen Ejecutivo" o "Mensajes Clave") → brief de marketing - Coincide con URL de GitHub o patrón
#\d+→ PR - Contiene
...o..→ rango de refs de git - Se resuelve a archivo/directorio existente → característica del código base
- De lo contrario → texto libre
Si no se proporciona ningún argumento, pregunta: "¿Sobre qué debería escribir? Puedes proporcionar una ruta de brief de marketing, URL/número de PR, rango de refs de git (ej. v1.0...v2.0), ruta de archivo/directorio, o simplemente describir el tema."
Si múltiples interpretaciones coinciden, confirma con el usuario.
Flujo de Proceso
digraph blog_post {
rankdir=TB;
"Resolve input" [shape=box];
"Phase 1: Discovery" [shape=box];
"Phase 2: Research" [shape=box];
"Phase 3: Configure" [shape=box];
"Phase 4: Outline" [shape=box];
"Outline approved?" [shape=diamond];
"Phase 5: Write" [shape=box];
"Phase 6: Output" [shape=box];
"Resolve input" -> "Phase 1: Discovery";
"Phase 1: Discovery" -> "Phase 2: Research";
"Phase 2: Research" -> "Phase 3: Configure";
"Phase 3: Configure" -> "Phase 4: Outline";
"Phase 4: Outline" -> "Outline approved?";
"Outline approved?" -> "Phase 4: Outline" [label="no, revise"];
"Outline approved?" -> "Phase 5: Write" [label="yes"];
"Phase 5: Write" -> "Phase 6: Output";
}
NO omitas fases. Haz preguntas a un ritmo natural. No abrumes, pero tampoco ralentices artificialmente. Si el usuario responde varias preguntas a la vez, acepta sus respuestas agrupadas y avanza.
Si el usuario dice "elige los valores predeterminados", "tú decide", o similar, elige valores predeterminados razonables según el contexto, indica lo que elegiste y pide una única confirmación antes de continuar.
Nunca hagas suposiciones sin confirmar.
Fase 1: Descubrimiento
Paso 1 - Analizar la entrada
| Tipo de entrada | Qué leer |
|---|---|
| Brief de marketing | Lee el brief - extrae declaración del problema, propuesta de valor, audiencia, mensajes clave, posicionamiento competitivo. Aún así haz el Paso 2 si el brief carece de contexto del producto, luego ve 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), enfócate en cambios visibles para el usuario. |
| Refs de git | git diff y git log entre los refs. Para rangos grandes, prioriza mensajes de commit y cambios visibles para el usuario. |
| Característica del código base | Lee los archivos/directorios especificados. |
| Texto libre | Analiza la descripción del usuario. Si carece de detalles (sin nombre de característica, sin propuesta de valor, sin contexto), pide al usuario más detalles o que apunte a un archivo/PR específico. Recurre a preguntas abiertas solo si no pueden. |
Cambios visibles para el usuario incluyen: nuevas características, 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 no estés seguro, enumera lo que encontraste y pregunta al usuario cuáles son relevantes.
Manejo de errores:
ghno instalado/autenticado → informa al usuario, sugieregh auth login, ofrece entrada alternativa- PR/ref inválido → dile al usuario, pide verificar
- Archivo no encontrado → pide la ruta correcta
Paso 2 - Leer contexto más amplio del producto
Lee si existen: README, docs/, package.json (o equivalente), referencias de marketing.
Objetivo: entender qué es el producto, para quién es y qué hace.
Si no se encuentra nada, pregunta: "No pude encontrar contexto del producto en el repositorio. ¿Puedes describir brevemente el producto y para quién es?"
Paso 3 - Presentar entendimiento
"Aquí está lo que entiendo:"
- Característica A - descripción corta
- Característica B - descripción corta
"¿Cuáles de estas debería cubrir la publicación del blog? ¿Algo que añadir, eliminar o corregir?"
Haz tantas preguntas como sea necesario para entender completamente el alcance. NO continúes hasta que el usuario confirme.
Paso 4 - Señalar elementos sensibles
Busca: cambios disruptivos (breaking changes), obsolescencias, correcciones de seguridad, requisitos de migración.
Si encuentras alguno, señálalo y pregunta cómo enmarcarlos antes de continuar.
Fase 2: Investigación de Blogs de la Competencia
Antes de configurar la publicación, busca publicaciones de blog similares en el espacio:
- Usa WebSearch para encontrar de 3 a 5 publicaciones de blog existentes que cubran el mismo tema, productos competidores o anuncios de características similares
- Analiza qué funciona y qué no en esas publicaciones - estructura, titulares, ganchos, palabras clave SEO, profundidad
- Identifica brechas de contenido - qué NO están cubriendo los competidores que esta publicación podría
- Usa estos hallazgos para informar la estrategia SEO, generación de titulares y estructura de contenido
Si WebSearch no está disponible, salta esta fase y confía en tu propio conocimiento.
Presenta un resumen breve al usuario:
"Encontré algunas publicaciones similares en el espacio. Esto es lo que noté:"
- [Hallazgos clave sobre lo que funciona]
- [Brechas de contenido / oportunidades]
- [Oportunidades de palabras clave SEO]
"Usaré estos conocimientos para dar forma a la publicación."
Fase 3: Configuración
Haz estas preguntas:
P1 - Audiencia: "¿Para quién es esta publicación de blog?" (desarrolladores, usuarios finales, tomadores de decisiones técnicas, audiencia general, otro)
P2 - Tono: Lee publicaciones de blog existentes, README y docs en el repositorio para detectar la voz del producto. Luego confirma:
"Basado en tu contenido existente, el tono parece [ej. conversacional y amigable para desarrolladores]. ¿Debería coincidir con eso o ir en una dirección diferente?"
Si no hay contenido existente para analizar, pregunta directamente qué tono quiere el usuario.
P3 - Tipo de publicación: Según la entrada y la audiencia, recomienda un tipo de publicación y confirma:
- Anuncio de característica - "Lanzamos X, aquí está por qué importa" (~600-1000 palabras)
- Técnico en profundidad - "Cómo construimos X, las decisiones y la arquitectura" (~1500-2500 palabras)
- Narrativa problema-solución - "Tienes el problema X, aquí está cómo esto lo resuelve" (~1000-2000 palabras)
"Dado el [entrada/audiencia], recomendaría una publicación de tipo [tipo] porque [razón]. ¿Suena bien?"
P4 - CTA: Infiere la llamada a la acción más apropiada según el contexto:
- Código abierto → da estrella al repositorio, contribuye, pruébalo
- SaaS → regístrate, prueba gratuita
- Actualización de característica → prueba la nueva característica, lee los docs
- Biblioteca/SDK → instálalo, lee la guía de migración
"Sugiero que el CTA sea: [CTA inferido]. ¿Quieres seguir con eso o algo diferente?"
P5 - Nivel de participación: "¿Qué tan involucrado quieres estar en el proceso de escritura?"
- A) Solo escríbelo - Me encargo de todo, elijo el mejor titular y guardo la publicación final. Puedes solicitar cambios después.
- B) Muéstrame el esquema primero - aprueba la estructura, luego escribo la publicación completa
- C) Guíame a través - aprobación del esquema, luego sección por sección con confirmación
Fase 4: Esquema
Genera un esquema estructurado:
## [Título de trabajo]
1. **Gancho/Introducción** - [enfoque: pregunta/estadística/declaración audaz/historia]
- Punto clave a establecer
- Transición al cuerpo
2. **Nombre de la sección** - [propósito]
- Puntos clave
- Recuento estimado de palabras
3. **Nombre de la sección** - [propósito]
- Puntos clave
- Recuento estimado de palabras
[...tantas secciones como sean necesarias]
N. **Conclusión** - [resumen + CTA]
- Conclusión clave a reforzar
- CTA: [acción específica]
Total estimado: ~X palabras
Si el nivel de participación es A, genera el esquema internamente sin mostrarlo. Para B y C, preséntalo y espera la aprobación.
Fase 5: Escribir
Proceso de escritura interno (siempre se ejecuta, independientemente del nivel de participación)
Para cada sección:
- Escribe la sección
- Auto-revisión: analiza si el contenido podría estructurarse de manera diferente, si falta contexto que el lector necesita para entender y asimilarlo, o si tiene lagunas que confundirían a alguien no familiarizado con el tema
- Relleno: si se encuentran piezas faltantes, añade párrafos de transición, contexto o reestructura antes de continuar
Si el nivel de participación es C, presenta cada sección después de la auto-revisión y obtén confirmación antes de continuar. Para A y B, ejecuta este proceso en silencio.
Titulares
Después de completar el cuerpo, genera 3-5 opciones de titular usando diferentes fórmulas:
- Cómo hacerlo ("Cómo [Producto] resuelve [problema]")
- Número/lista ("3 razones por las que [característica] cambia [flujo de trabajo]")
- Pregunta ("¿Cansado de [punto de dolor]?")
- Declaración audaz ("[Característica] es la forma más rápida de [resultado]")
- Antes/después ("[Dolor] → [Resultado]: Cómo [característica] lo hace posible")
Recomienda uno y explica por qué funciona mejor para la audiencia, SEO y contexto de esta publicación. También explica las compensaciones de los otros.
Para los niveles de participación B y C, presenta las opciones y obtén la selección del usuario antes de continuar. Para el nivel A, usa tu recomendación.
Prioriza la legibilidad sobre las restricciones SEO. Escribe el mejor titular primero. Si no se ajusta al límite de 50-60 caracteres para el título SEO, crea una etiqueta de título más corta separada para el frontmatter.
Frontmatter SEO
Genera como frontmatter YAML en la parte superior de la publicación:
---
title: "[Titular seleccionado]"
meta_description: "[140-160 caracteres, incluye la palabra clave principal, propuesta de valor convincente]"
primary_keyword: "[palabra clave objetivo principal]"
secondary_keywords: ["keyword1", "keyword2", "keyword3"]
long_tail_keywords: ["frase más larga 1", "frase más larga 2"]
slug: "[slug-amigable-para-url]"
---
Reglas:
- Etiqueta de título: 50-60 caracteres, palabra clave principal al inicio
- Meta descripción: 140-160 caracteres, escrita para humanos, incluye propuesta de valor única
- Palabras clave informadas por la investigación competitiva de la Fase 2
- Sin relleno de palabras clave - solo lenguaje natural
Reglas de formato de contenido
- Párrafos cortos: máximo 2-4 oraciones
- Subtítulos: usa H2 para secciones principales, H3 para subsecciones. Los subtítulos deben funcionar como un esquema escaneable por sí mismos.
- Frase clave en negrita para apoyar la exploración en patrón F
- Viñetas y listas para cualquier conjunto de 3+ elementos
- 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.
Gancho/Introducción
La introducción tiene tres componentes:
- Gancho (primeras 1-2 oraciones) - una estadística sorprendente, afirmación audaz, punto de dolor relatable o pregunta provocativa. Debe crear curiosidad o resonancia emocional en menos de 3 segundos de lectura.
- Autoridad - establece brevemente por qué esto importa o por qué el lector debería confiar
- Promesa - indica claramente lo que el lector obtendrá de esta publicación
Mantén la introducción en 3-5 párrafos cortos. Sin muros de texto.
Conclusión
- Reitera la conclusión principal (NO introduzcas nuevas ideas)
- CTA único y claro con verbo de acción ("Pruébalo ahora", "Da estrella al repositorio", "Comienza tu prueba gratuita")
- Opcionalmente, termina con una declaración prospectiva o pregunta para iniciar discusión
Contenido visual
Genera directamente cuando sea posible:
- Diagramas de arquitectura → bloques de código mermaid o SVG en línea
- Diagramas de flujo de datos → bloques de código mermaid
- Tablas de comparación → tablas markdown
- Ejemplos de código → bloques de código con resaltado de sintaxis
Para imágenes que necesitan creación externa:
<!-- TODO: Añadir imagen aquí -->
<!-- Sugerencia: [descripción de lo que debería mostrar la imagen] -->
<!-- Prompt LLM: "[prompt listo para usar para un modelo de generación de imágenes, ej. 'Una ilustración limpia y minimalista que muestra un panel con alternancia de modo oscuro, estilo de diseño plano, estética de herramientas para desarrolladores, relación 16:9']" -->
Usa elementos visuales siempre que ayuden a la comprensión - después de explicar un concepto complejo, al comparar opciones, o al mostrar cambios de UI.
Ejemplos de código
Para audiencias de desarrolladores, incluye al menos un ejemplo de código que muestre la característica en acción. Prefiere fragmentos mínimos y ejecutables (5-15 líneas). Muestra antes/después al demostrar una mejora.
Fase 5b: Revisión del Borrador Completo
Después de que todas las secciones estén escritas y el titular seleccionado, ensambla la publicación completa (frontmatter + cuerpo).
- Nivel A: Omite la revisión. Procede directamente a la salida. Presenta la publicación final y guárdala. El usuario puede solicitar cambios después.
- Nivel B: Presenta el borrador completo al usuario para revisión antes de guardar. "Aquí está la publicación completa. ¿Quieres algún cambio antes de que la guarde?"
- Nivel C: El usuario ha visto cada sección individualmente, pero aún así presenta el borrador ensamblado para una revisión final. "Aquí está la publicación completa. ¿Quieres algún cambio antes de que la guarde?"
Para B y C, si el usuario solicita revisiones, hazlas y presenta de nuevo. Solo procede a la salida una vez que el usuario apruebe.
Fase 6: Salida
Primero detecta el directorio de blog existente. Verifica:
content/blog/,src/pages/blog/,_posts/,blog/,posts/,articles/
Si se encuentra, usa ese directorio. Si no, usa por defecto blog/posts/.
Preséntale al usuario:
"Guardaré esto en
[ruta-detectada-o-por-defecto]/<slug>.md. ¿Quieres en otro lugar, o debería omitir el guardado y solo imprimirlo?"
Crea el directorio si no existe.
Si el archivo ya existe: pregunta si sobrescribir o crear una copia versionada.
Manejo de Errores
ghno disponible → informa al usuario, ofrece entrada alternativa- PR/ref inválido → pide al usuario verificar
- Sin contexto del producto → pide al usuario describir el producto
- WebSearch no disponible → omite la Fase 2, procede con tu propio conocimiento
- Sin directorio de blog existente → usa por defecto
blog/posts/, créalo
Lo que este skill NO hace
- Generar copias para redes sociales (usa
/social-copypara eso) - Publicar o desplegar la publicación en cualquier plataforma
- Generar briefs de marketing (usa
/marketing-briefpara eso) - Crear múltiples variantes para diferentes audiencias - ejecuta el skill de nuevo para una audiencia diferente