tjdgus4560/cardnews-maker-skill

Card-News Maker (카드뉴스 메이커)

Convierte un tema, un artículo fuente (URL) o un archivo de borrador en un conjunto de imágenes de card-news 800×800 pulidas. El usuario trae un nuevo tema cada vez; tú lees/derivas el contenido, lo estructuras en tarjetas, las renderizas y luego ejecutas un bucle de auto-revisión y corrección antes de entregar.

La apariencia es fija (para que cada conjunto se sienta como una serie), pero el tema de color se adapta al tema cada vez. El diseño, la tipografía, el espaciado y el bucle de revisión se mantienen constantes.

Cuándo preguntar vs. cuándo decidir

El usuario quiere explícitamente que se le pregunte sobre cualquier cosa genuinamente ambigua en lugar de que tú adivines. Usa AskUserQuestion (ofreciendo primero una opción recomendada) cuando la respuesta cambiaría significativamente el resultado y no sea inferible. En caso contrario, decide y explica brevemente tu elección.

Decide tú mismo (no preguntes):

• Número de tarjetas — ajústalo al contenido, normalmente 8–15 (portada + cuerpo + cierre).
• Tema de color — elige uno que se adapte al tema/marca (consulta las referencias).
• Diseño por tarjeta (tarjeta de cuerpo estándar vs. tarjeta de estadística vs. diagrama/lista de verificación).
• Redacción en coreano, énfasis en textos, etiquetas de encabezado.

Pregunta al usuario (cuando no esté claro):

• Ambigüedad de la fuente: solo un tema de una línea sin fuente y el alcance es amplio → pregunta si debe buscar en la web, o qué enfoque/profundidad desean.
• El título de portada cuando no surge un título único claro (por defecto: propón uno + ofrece una alternativa mejor, que ellos elijan).
• Audiencia/tono si el tema puede abordarse de varias maneras (p. ej., resumen ejecutivo vs. explicación para principiantes) y cambia materialmente el texto.
• Cualquier cosa que el usuario marque como "판단 애매" — preséntalo como pregunta.

Cuando se decida una preferencia recurrente, está bien anotarla para que las ejecuciones futuras sean más fluidas, pero nunca bloquees todo el trabajo con una pregunta que puedas responder con un valor predeterminado sensato.

Flujo de trabajo

1. Obtener el contenido

• URL → obténla (WebFetch) y extrae la tesis, los puntos clave, la terminología, los números/citas notables y las conclusiones principales.
• Texto / archivo de borrador → léelo; trata un borrador por capítulos proporcionado como el esqueleto principal. Puedes refinarlo ligeramente, pero mantén la estructura del usuario.
• Solo un tema de una línea → si el alcance es amplio y no hay fuente, pregunta si deben buscar en la web o qué enfoque quieren antes de inventar contenido.

Mantente fiel a la fuente. Evita la sobreinterpretación. Cuando añadas el ángulo de "lo que debemos aprender / 시사점", enmárcalo como lecciones extraídas de la fuente, no como prescripciones personales. Reformula cualquier imperativo de "haz X / 하라" en observaciones ("X es importante", "se vuelve más fuerte cuando X").

2. Planificar el conjunto

Decide el número de tarjetas y el rol de cada una. Un arco típico: portada → gancho/introducción → contexto → conceptos centrales (una idea por tarjeta) → una tarjeta de estadística o diagrama donde ayude a la transferencia → mensaje de cierre (+ enlace fuente).

Usa una idea por tarjeta. Si el cuerpo de una tarjeta se desborda, divídela.

Elige un tema de color que se ajuste al tema y lee references/design-system.md para conocer los tokens exactos, el diseño de las tarjetas y los patrones de componentes. Lee references/card-patterns.md para obtener variantes de tarjetas ya preparadas (portada, cuerpo, estadística, diagrama, lista de verificación, cierre).

3. Construir el HTML

Usa scripts/build.js como punto de partida: ya codifica el sistema de diseño (CSS base, chip de encabezado, título, divisor, cuerpo con tramos resaltados, pie de página, decoración de onda de río) y genera un archivo HTML por tarjeta en cards/. Cópialo en el directorio de trabajo y edita las definiciones de las tarjetas y los colores del tema para este asunto. No reescribas el motor de diseño desde cero.

4. Renderizar a PNG

Ejecuta scripts/render.js (Playwright + Chromium, deviceScaleFactor 2 → PNG nítidos de 800×800 en out/). Configuración única si Playwright no está instalado: npm install playwright && npx playwright install chromium.

5. Bucle de auto-revisión y corrección (hazlo siempre)

Esto es obligatorio, no opcional: es lo que hace que el resultado se sienta terminado.

• Vuelve a leer los PNG renderizados (herramienta Read) e inspecciona cada tarjeta.
• Verifica: texto del cuerpo que choca con el pie de página, desequilibrio de espacio vacío, desbordamiento de texto / saltos de línea incómodos, contraste/legibilidad, encabezado y pie de página coherentes, números de página correctos y recuento total.
• Corrige los problemas en build.js, vuelve a renderizar y vuelve a verificar las tarjetas afectadas.
• Solo entrega una vez que todo el conjunto esté limpio. Consulta references/review-checklist.md para obtener la lista completa y las correcciones comunes.

6. Entrega

Dónde guardar — elige la ubicación de salida según el contexto, para que los resultados caigan donde el usuario los buscaría:

1. Si estás trabajando dentro de un proyecto/repo (la sesión tiene una raíz de proyecto — p. ej., un repo git, o el usuario está claramente operando en un directorio de trabajo específico): guarda todo bajo esa raíz del proyecto, en <raíz-del-proyecto>/cardnews/<tema>/. Coloca también los artefactos intermedios allí (el build.js de trabajo, cards/*.html, out/*.png) para que el conjunto sea reproducible y versionable junto con el proyecto. Este es el valor predeterminado siempre que exista un contexto de proyecto.
2. Si no hay contexto de proyecto (una solicitud única y ad hoc sin un repo de trabajo): guarda en una ubicación global apropiada para el sistema operativo — <home>/cardnews/<tema>/ (funciona en Windows, macOS y Linux por igual; evita codificar Downloads).
3. Si el usuario nombra una ubicación, respétala por encima de las anteriores.

Indica dónde guardaste los archivos. La salida predeterminada es solo PNG (más el HTML intermedio al guardar en un proyecto, según la regla 1). Construye el PDF A4 solo cuando se solicite (u ofrécelo de forma proactiva) usando scripts/make_pdf.py, que coloca cada tarjeta en una página A4 con margen izquierdo/derecho cero (la tarjeta llena el ancho de la página) y márgenes superior/inferior iguales — lee su comentario de encabezado para conocer el comportamiento.

Mantén los archivos de trabajo (build.js, etc.) en una carpeta del proyecto para que el usuario pueda modificar el texto y volver a ejecutar node build.js && node render.js.

Valores predeterminados (estilo propio de este skill)

• Tamaño: 800×800 cuadrado, escala de renderizado 2×.
• Estructura por tarjeta: chip de encabezado (número + etiqueta) → título → divisor → cuerpo con tramos resaltados selectivamente → pie de página unificado (fuente · NN / total).
• Portada y cierre: degradado a sangre completa en el color del tema, motivo de onda; la tarjeta de cierre lleva el enlace de la fuente.
• Salida: PNG por defecto; PDF A4 bajo petición.
• Idioma: texto en coreano (los términos técnicos / identificadores se mantienen en su forma original).

Recursos

• references/design-system.md — temas de color, tokens CSS, anatomía de componentes.
• references/card-patterns.md — variantes de tarjetas copiables con ejemplos.
• references/review-checklist.md — qué verificar y cómo corregir cada problema.
• scripts/build.js — constructor de tarjetas HTML (motor de diseño + definiciones de tarjetas).
• scripts/render.js — renderizador Playwright de HTML a PNG.
• scripts/make_pdf.py — ensamblador de PDF A4 (margen lateral cero, margen superior/inferior).