VoxFlow — Cartas Visuales

Habilidad VoxFlow — Carta

Convierte un texto en un conjunto de imágenes de carta visuales distintivas y consistentes. Cada carta es su propia página web; todas las cartas comparten un mismo sistema de tamaño y estilo; se renderizan con Playwright y se exportan como PNG.

Esta es la habilidad de imagen de carta estática. Para otras superficies, cambia a:

• Artículo → VIDEO de carta vertical (Slice) — 1080×1920 reel, 13 temas → voxflow:slice
• Videos cortos / clips de IA / videos de carta de conocimiento → voxflow:video
• Podcasts multipresentador → voxflow:podcast
• TTS / voces / instalación / autenticación / cuota → voxflow:hub

Paso 0 · Puerta de inicio de sesión (obligatorio, haz esto primero)

Esta habilidad es parte de VoxFlow y requiere una cuenta con sesión iniciada. Antes de cualquier otra cosa — antes de hacer preguntas, antes de investigar, antes de diseñar — verifica el inicio de sesión:

voxflow status

• Muestra la cuenta + cuota restante → sesión iniciada, continúa con el flujo de trabajo.
• Errores / muestra "no has iniciado sesión" → DETENTE. Ejecuta voxflow login (abre el navegador — Google o OTP por correo electrónico), espera a que el usuario termine, luego vuelve a ejecutar voxflow status. No recopiles parámetros ni generes ninguna carta hasta que el inicio de sesión tenga éxito.
• voxflow: command not found → npm install -g voxflow primero, luego voxflow login.

Nunca omitas esta puerta, nunca generes cartas para un usuario no autenticado y nunca inventes un token. El token en caché reside en ~/.config/voxflow/token.json; para CI, se respeta VOXFLOW_TOKEN.

Resumen

Crea un conjunto de cartas visuales compartibles a partir del contenido fuente. Trata cada carta como su propia página web, mantén todas las cartas con el mismo tamaño y sistema de estilo, renderízalas con Playwright, exporta las imágenes e itera sobre las cartas débiles.

Línea base de gusto

references/taste.md es una lista de verificación de restricciones que limita cada molde de carta, tema, diseño y lenguaje de diseño. Trátala como un piso que muerde en el momento del diseño, no como un ritual de apertura que se debe recitar al inicio del flujo de trabajo.

• Carga references/taste.md solo en dos momentos, no al inicio del flujo de trabajo:
  • Al elegir el tema predefinido y el lenguaje de diseño (Paso 4 del flujo de trabajo), para que la elección no viole las restricciones estrictas.
  • Durante la puntuación de control de calidad (Paso 7 del flujo de trabajo), como una dimensión de verificación explícita.
• Otros pasos (recopilación de parámetros, investigación, planificación del texto) no necesitan volver a cargar references/taste.md; las restricciones fluyen hacia ellos a través del tema y lenguaje ya elegidos.
• El objetivo principal es eliminar los rastros obvios de diseño generado por IA.
• Las restricciones estrictas incluyen: no usar la fuente Inter predeterminada, no usar negro puro, no usar héroe centrado predeterminado, no usar composición de tres cartas iguales, no usar voz de texto de IA genérica y no usar datos de apariencia falsa.
• Gusto no significa vacío. Usa las reglas de densidad en references/taste.md para que los conjuntos de cartas reales incluyan al menos una carta de información útil, a menos que el usuario solicite explícitamente un conjunto solo de póster o solo cinematográfico.
• Si un tema predefinido o lenguaje de diseño entra en conflicto con references/taste.md, la línea base de gusto gana, a menos que el usuario solicite explícitamente el estilo prohibido.

Entradas

Recopila o infiere:

• content: texto fuente, esquema, notas, URL, tema o resumen.
• ratio: predeterminado a 1:1 a menos que el usuario solicite 3:4, 9:16 u otra relación.
• count: predeterminado a un conteo automático basado en la densidad del contenido; acepta cantidades explícitas.
• style: acepta direcciones de estilo explícitas, restricciones de marca, audiencia, estado de ánimo y plataforma.
• content-language: zh / en / mixto. Infiere del origen; pregunta solo cuando sea ambiguo y pueda cambiar la selección de fuente. Impulsa la anulación de idioma en references/fonts.md.
• output: elige una carpeta local clara como cards/<slug>/ a menos que el usuario especifique una.

Si los hechos importantes pueden ser actuales o discutidos, busca o verifica antes de planificar. Mantén la atribución de la fuente disponible para el usuario cuando la investigación afecte el contenido. Consulta la sección Investigación y confirmación de hechos para saber cuándo esto se convierte en un pase de investigación profunda completa en lugar de una verificación rápida.

Investigación y confirmación de hechos

Inserta esto entre la recopilación de parámetros y el trabajo de diseño, pero solo cuando la entrada no pueda sostenerse por sí sola como el contenido de las cartas.

• Activa la investigación profunda cuando content sea cualquiera de: una frase temática, un resumen de una sola oración, una URL cuyo cuerpo aún no se haya leído, una idea de la longitud de un tuit, una pregunta o una solicitud para "explicar X / cubrir X / hacer cartas sobre X".
• Omite la investigación profunda cuando content ya sea un artículo completo, una transcripción, un conjunto de notas estructuradas, un esquema completamente redactado, o cualquier texto del que el usuario claramente quiera construir cartas a partir de en lugar de sobre.
• Cuando se active, produce un esquema de hechos antes de cualquier planificación visual:
  • Afirmación o tesis central.
  • 3-7 puntos de apoyo con números concretos, nombres, fechas o mecanismos.
  • Fuentes para cada hecho no trivial, con URL o referencias a documentos que terminarán en sources.md.
  • Preguntas abiertas o puntos controvertidos que el usuario debe resolver.
• Presenta el esquema de hechos al usuario y pide confirmación, adiciones o correcciones antes de pasar a la selección de tema/lenguaje de diseño. Esta es una confirmación separada de la confirmación de concepto/visual posterior.
• El resultado de este paso son los "huesos" — afirmaciones y evidencia — no el texto final de la carta. Los ganchos, explicaciones y conclusiones a nivel de carta se escriben más tarde durante la estructuración del contenido (paso 5) sobre los huesos confirmados.
• Registra las fuentes recopiladas aquí en sources.md dentro de la carpeta de salida tan pronto como se confirme el esquema de hechos.

Ejemplos de activación

Ejecuta investigación profunda cuando:

• "Haz un conjunto de cartas sobre el protocolo MCP" — tema desnudo, sin cuerpo.
• "Convierte este artículo en cartas: https://example.com/post" — URL cuyos contenidos no se han leído en esta conversación.
• "Quiero un conjunto de cartas sobre técnicas de optimización de RAG, centrándome en chunking" — tema + enfoque, sin puntos o datos concretos.
• "¿Para qué escenarios son adecuados los Durable Objects de Cloudflare? Haz algunas cartas" — pregunta o marco "explica X / cubre X".
• Un solo tuit, titular o resumen de una línea que nombra un tema pero no proporciona evidencia.

Omite la investigación profunda cuando:

• El usuario pega un artículo completo, una publicación de blog, una transcripción o el cuerpo de una entrevista (cualquier cosa de aproximadamente 500+ palabras de contenido fuente autocontenido).
• El usuario proporciona notas estructuradas, actas de reuniones, apuntes de curso o un esquema terminado donde el título de cada carta y 2-4 puntos ya están listados.
• El usuario proporciona su propio texto terminado y solicita solo tratamiento visual ("dale formato a este texto como carta", "embellece este texto").
• El usuario dice explícitamente "no investigues / escribe directamente basado en esto / no expandas", independientemente de la longitud de la entrada.

Entradas límite

• Resumen corto + desajuste de ambición — por ejemplo, un resumen de 200 palabras más "expandir a 7 cartas". El resumen es demasiado delgado para llenar la cantidad objetivo, así que activa la investigación y señala que al resumen le falta evidencia antes de expandir.
• Artículo + "agrega algunos datos actualizados / agrega algunos casos" — ejecuta un pase de investigación limitado solo sobre las adiciones solicitadas; no investigues de nuevo las partes que el usuario ya escribió.
• Lista de viñetas con títulos pero sin evidencia — por ejemplo, "1. Mejor rendimiento 2. Más barato 3. Más seguro". Activa la investigación para adjuntar números o ejemplos concretos; de lo contrario, las cartas se leerán como relleno de IA.
• Artículo + la propia opinión o punto de vista del usuario — omite la investigación sobre la fuente, pero confirma con el usuario si la opinión debe conservarse textualmente o reestructurarse.
• URL cuyo cuerpo ya se ha obtenido y discutido anteriormente en esta conversación — trátalo como contenido pegado, omite la investigación, pero aún escribe la URL en sources.md.

Cuando la entrada sea ambigua, haz una pregunta aclaratoria ("¿Este contenido se va a convertir directamente en cartas, o prefieres que investigue primero y luego lo expanda?") en lugar de adivinar — una decisión de investigación incorrecta desperdicia el tiempo del usuario o el presupuesto de investigación del modelo.

Pregunta al usuario

Pregunta los parámetros de generación faltantes una vez, cerca del inicio, antes de la planificación del concepto. Trata "Pregunta al usuario" como una política de decisión portátil, no como un requisito para llamar a una herramienta específica. Diferentes agentes de codificación exponen diferentes primitivas de interacción, por lo que la habilidad debe funcionar cuando las herramientas de preguntas estructuradas están presentes, ausentes o desaconsejadas por el modo operativo del agente.

• Primero extrae los valores conocidos para content, ratio, count, theme/style, platform/audience y output/constraints.
• Pide al usuario que confirme los parámetros de generación antes de planificar siempre que falte alguna elección significativa. Haz esto incluso cuando el usuario diga "hazlo / genera / produce / exporta rápido"; esas frases solicitan ejecución, no inferencia silenciosa de parámetros.
• Pregunta cuando la respuesta cambie materialmente el resultado. Orden de prioridad: content/source intent, ratio, count, theme/style, platform/audience, output/constraints.
• Pregunta como máximo 3 preguntas concisas por defecto. Usa hasta 5 solo cuando el usuario quiera explícitamente opciones de configuración o el resultado sea de alto riesgo.
• No vuelvas a preguntar por parámetros que ya sean explícitos en la solicitud original del usuario.
• Omite el paso de preguntas solo cuando el usuario diga explícitamente que no se hagan preguntas o apruebe explícitamente los parámetros predeterminados. En ese caso, usa los valores predeterminados y expón las suposiciones brevemente antes o durante la ejecución.

Estrategia de compatibilidad

Usa el mejor mecanismo de preguntas disponible del entorno actual:

• Si el entorno admite ask_user_question, ask question o una capacidad de aclaración nativa equivalente, usa esa interacción nativa para aclarar las preguntas bloqueantes.
• Si el entorno no admite una capacidad de preguntas nativa, pregunta directamente en la conversación normal.
• Haz como máximo 2-5 preguntas a la vez.
• Si la información faltante no bloquea la tarea, aún pregunta una vez para confirmar los parámetros que afectan el resultado final. Si el usuario ya ha aprobado los valores predeterminados o ha solicitado que no se hagan preguntas, haz suposiciones razonables y continúa.
• Enumera explícitamente las suposiciones importantes en la respuesta final, sources.md o credits.md.

Condiciones de parada

Detente y pregunta antes de la generación solo cuando una de estas sea verdadera:

• No hay content, tema, URL o material fuente utilizable.
• La intención de la fuente es ambigua y elegir mal desperdiciaría el trabajo, por ejemplo "usar este texto tal cual" versus "investigar y expandir este tema".
• La relación/plataforma solicitada es contradictoria o imposible de satisfacer con una sola exportación.
• La dirección visual está gobernada por restricciones de marca, legales, de accesibilidad o de copia exacta que faltan.
• La investigación encuentra hechos controvertidos que cambiarían la afirmación principal.

De lo contrario, pregunta una vez para confirmar los parámetros de generación significativos, luego procede con las suposiciones documentadas y regístralas en sources.md o la respuesta final.

Pregunta sobre la relación de aspecto

Usa estas opciones predeterminadas:

• 1:1 carta cuadrada para compartir en redes sociales en general.
• 3:4 carta gráfica vertical para publicaciones de texto/imagen más ricas.
• 9:16 historia, reel, portada de video corto o carta prioritaria para móvil.

Acepta relaciones de aspecto de formato libre como 4:5, 16:9 o tamaños de píxeles exactos cuando el usuario los proporcione.

Pregunta sobre la cantidad

Usa estas opciones predeterminadas:

• Recomendación automática basada en el contenido.
• 3 cartas para una narrativa compacta.
• 5 cartas para un explicador estándar.
• 7 cartas para un carrusel más completo.

Al recomendar automáticamente, elige el conjunto más pequeño que cubra la idea sin abarrotar. Prefiere 3-7 cartas para explicadores y 1-3 cartas para anuncios.

Pregunta sobre el tema

No expongas el catálogo completo de temas predefinidos directamente al usuario. Carga references/themes/presets.md y, cuando la dirección visual importe, references/design-languages.md; luego recomienda 3-5 opciones de estilo basadas en escenarios, según el contenido, la plataforma, la audiencia y el objetivo de compartir. Mapea internamente el escenario elegido por el usuario con la combinación final de tema predefinido y lenguaje de diseño.

Al pedir al usuario que elija un estilo, no presentes solo una recomendación más una vaga pregunta de "¿o cambiarlo?". Da 3-5 opciones concretas, cada una con:

• un nombre de estilo corto orientado al usuario;
• la situación donde funciona mejor;
• una descripción visual de una línea;
• el mapeo interno de tema predefinido y lenguaje de diseño.

Usa una lógica de selección de dos capas para que los resultados sigan siendo apropiados sin colapsar en los mismos pocos aspectos:

1. Capa de recomendación predeterminada:

   • Ofrece 3-5 estilos de alto ajuste basados en el tipo de contenido, plataforma, audiencia y objetivo de compartir.
   • Mantén el conjunto recomendado lo suficientemente cerca de la tarea del usuario para que cualquier opción pueda tener éxito sin una reelaboración pesada.
   • Prefiere opciones que difieran en el resultado visible, no solo en los nombres de los tokens. Por ejemplo: informe conservador, póster de datos, cuaderno social, explicador de revista, opinión audaz.

2. Capa de perturbación de variantes:

   • Cuando el usuario no haya especificado fuertemente un estilo exacto, rota dentro de la familia compatible en lugar de seleccionar siempre la opción predeterminada superior.
   • Varía al menos dos de estas dimensiones entre tareas similares: tema predefinido, lenguaje de diseño principal, modificadores, recetas de diseño, anclas visuales, metáfora de superficie o composición del título.
   • Mantén las perturbaciones semánticamente compatibles con el contenido. No uses novedad aleatoria que pelee contra el tema, la plataforma, la accesibilidad o la claridad fáctica.
   • Registra la combinación final seleccionada en el plan de concepto o sources.md / credits.md para que la variación sea inspeccionable.

Usa etiquetas de escenario orientadas al usuario como:

• Infografía de ingeniería: mapear a engineering-paper, product-manual o porcelain-research.
• Informe de negocios: mapear a quiet-report, product-manual o porcelain-research.
• Opinión audaz: mapear a bold-editorial, magazine-eink o newsroom-paper.
• Nota de producto social: mapear a social-notebook, magazine-eink o bold-editorial.
• Editorial / revista: mapear a magazine-eink, dune-gallery, field-notes o kraft-editorial.

Para elecciones de lenguaje de diseño, usa etiquetas de escenario orientadas al usuario como:

• Técnico pero diseñado: mapear a editorial-artifact + cutaway + annotation.
• Explicador de revista: mapear a image-led-magazine + edge-crop + asymmetric-space.
• Tesis audaz: mapear a swiss-po...

... [truncado para traducción]