Agente Periodista de Datos (Data2Story)

¿Qué hace Agente Periodista de Datos (Data2Story)?

Convierte $ARGUMENTS en un blog. Orquestra los roles siguientes en secuencia.

Configuración

Resuelve las rutas antes de hacer cualquier otra cosa:

• Nunca uses rutas locales de máquina codificadas y nunca le pidas al usuario que exporte variables de entorno.
• Resuelve SKILL_DIR = el directorio que contiene este SKILL.md (.../skills/data2story)
• Resuelve ARCHIVE_DIR = el directorio ancestro que contiene skills/ (dos niveles arriba de SKILL_DIR, es decir, SKILL_DIR/../..)
• Resuelve DATA2STORY_ROOT = el padre de ARCHIVE_DIR
• Los comandos siguientes usan marcadores de posición simbólicos como ARCHIVE_DIR; reemplázalos con rutas resueltas y entrecomilladas antes de ejecutar Bash.
• DATA_NAME = el nombre de la carpeta del conjunto de datos (ej. pick_a_card)
• DATA_DIR = si $ARGUMENTS es una ruta existente, usa esa ruta; en caso contrario, usa DATA2STORY_ROOT/data/{DATA_NAME}
• TIMESTAMP = la hora actual con formato MMDD_HHMM (ej. 0401_1618): date +%m%d_%H%M (ejecutar en bash)
• PROJECT_DIR = DATA2STORY_ROOT/project/{DATA_NAME}/blog_{MODEL}_{TIMESTAMP}
• Crea PROJECT_DIR/, PROJECT_DIR/assets/, PROJECT_DIR/code/

Archivado

Inmediatamente después de crear PROJECT_DIR, toma una instantánea de las habilidades actuales:

mkdir -p PROJECT_DIR/archival
cp -r ARCHIVE_DIR/skills PROJECT_DIR/archival/skills

Esto preserva las versiones exactas de las habilidades utilizadas en esta ejecución.

Herramientas disponibles

Todas las herramientas multimedia se enrutan a través de OpenRouter. Establece OPENROUTER_API_KEY antes de cualquier llamada de generación.

La generación de medios es trabajo del Diseñador, por lo que las herramientas multimedia (texto-a-imagen, texto-a-video, imagen-a-video, texto-a-música, embeddings) residen en SKILL_DIR/designer/scripts/openrouter-*/. La lista completa (modelos predeterminados e invocaciones exactas de python3 ...) está en designer/references/tools.json; la documentación completa de cada herramienta está en su propio SKILL.md bajo SKILL_DIR/designer/scripts/openrouter-*/.

Resumen del Pipeline

El pipeline es una única secuencia lineal que produce un blog HTML trazable a partir de datos sin procesar:

DATA → Detective → Analista → Editor → Diseñador → Programador → Auditor → Inspector → index.html + viewer.html final

Ejecuta cada etapa en orden. Cada etapa lee los artefactos anteriores antes de comenzar. No pases a la siguiente etapa hasta que el artefacto actual esté completo.

Etapa 1 — Detective

Entrada: DATA_DIR Salida: PROJECT_DIR/detective.json Qué hace: Investiga el contexto externo — conocimiento de fondo, historia del dominio, hallazgos relacionados, por qué estos datos son importantes. Cada hallazgo obtiene un ID det_xx.

Etapa 2 — Analista

Entrada: DATA_DIR, PROJECT_DIR/detective.json Salida: PROJECT_DIR/code/*.py, PROJECT_DIR/analyst.json Qué hace: Análisis cuantitativo exhaustivo de los datos, informado por el contexto del detective. Todo el código se guarda en code/ como scripts ejecutables. Cada hallazgo obtiene un ID ana_xx con calculation (archivo + líneas + salida) y data_table (datos listos para gráficos).

Etapa 3 — Editor

Entrada: PROJECT_DIR/detective.json, PROJECT_DIR/analyst.json Salida: PROJECT_DIR/editor.md, PROJECT_DIR/editor.json Qué hace: Decisiones editoriales — qué hallazgos importan, cuál es el arco narrativo, qué argumenta el blog. Cada sección obtiene un ID edt_xx con referencias explícitas a hallazgos ana_xx y contexto det_xx. Sin diseño visual.

Etapa 4 — Diseñador

Entrada: PROJECT_DIR/editor.md, PROJECT_DIR/editor.json, PROJECT_DIR/analyst.json Salida: PROJECT_DIR/designer.json, PROJECT_DIR/assets/* Quée hace: Decisiones creativas visuales basadas en datos — cómo presentar cada punto usando gráficos, imágenes, vídeo, audio, mapas, interactivos, llamadas de estadísticas, instancias o solo texto cuando sea apropiado. La mezcla de medios debe surgir de las propiedades del conjunto de datos, no de una lista de verificación fija. La página debe ser multimedia por defecto: toma prestado el lenguaje visual de la habilidad compartida frontend-design y usa los cinco canales (gráfico, imagen, vídeo, audio, interactivo/mapa) a menos que la alternativa documentada de un canal se fabrique o sea puramente decorativa. Cada elemento visual obtiene un ID des_xx con data_source que apunta a data_tables de ana_xx cuando está basado en datos. Genera los activos seleccionados. Sin HTML.

Etapa 5 — Programador

Entrada: PROJECT_DIR/editor.md, PROJECT_DIR/editor.json, PROJECT_DIR/analyst.json, PROJECT_DIR/designer.json Salida: PROJECT_DIR/index.html Qué hace: Implementa el blog final en HTML. Aplica el tema/acento registrado en designer.json page_rhythm y toma prestadas recetas de componentes + tokens de la habilidad frontend-design. Resuelve los datos de los gráficos desde analyst.json data_tables (SIN acceso a datos sin procesar). Etiqueta cada elemento con atributos data-edt, data-ana, data-det, data-des para la trazabilidad.

Etapa 6 — Auditor

Entrada: PROJECT_DIR/index.html Salida: PROJECT_DIR/index.html (modificado), PROJECT_DIR/auditor.json Qué hace: Detecta y corrige problemas de maquetación (superposición, espaciado, alineación) sin cambiar el contenido ni la intención del diseño. Se ejecuta automáticamente después del Programador para garantizar que los elementos visuales estén correctamente envueltos y espaciados.

Llamada: Skill auditor PROJECT_DIR

Etapa 7 — Inspector

Entrada: PROJECT_DIR/index.html, todos los archivos JSON Salida: PROJECT_DIR/inspector.json, PROJECT_DIR/viewer.html Qué hace: Ejecuta la verificación de trazabilidad a nivel de oración y genera un visor interactivo. Dos pasos:

python3 SKILL_DIR/inspector/scripts/verify.py PROJECT_DIR --log-errors
python3 SKILL_DIR/inspector/scripts/generate_viewer.py PROJECT_DIR

El paso 1 produce inspector.json (mapeo oración → evidencia). El paso 2 produce viewer.html (autónomo, funciona con file:// — no necesita servidor). Consulta inspector/SKILL.md para más detalles.

Trazabilidad: flujo de IDs a través del pipeline

det_01 ──┐
det_02 ──┤
         ├──▶ ana_01 (basado_en: [det_02]) ──┐
         │    ana_02 (basado_en: [])          ├──▶ edt_01 (hallazgos: [ana_01, ana_02], contexto: [det_01]) ──▶ des_01 (sección: edt_01, data_source: ana_01)
         │    ana_03 (basado_en: [det_01])    │    edt_02 (hallazgos: [ana_03], contexto: [det_02])         ──▶ des_02 (sección: edt_02, data_source: ana_03)
         └────────────────────────────────────┘

Cada valor en el HTML final se puede rastrear: HTML data-des="des_01" → designer.json des_01.data_source="ana_01" → analyst.json ana_01.calculation.code → verificable.

Reglas de transferencia

• Cada artefacto debe estar completo antes de que comience la siguiente etapa.
• Si falta una sección requerida en un artefacto, corrígela antes de continuar.
• Puerta de riqueza multimedia (después del Diseñador, antes del Programador): designer.json debe ejercitar los cinco canales (gráfico, imagen, vídeo, audio, interactivo_o_mapa). Para cualquier canal marcado como used:false, confirma que se probó genuinamente su alternativa documentada y que se registró una razón basada en los datos en meta.media_decisions. Si se omitió un canal por conveniencia y no porque los datos no lo puedan soportar, devuélvelo al Diseñador antes de que se ejecute el Programador.
• Todos los activos generados van solo a PROJECT_DIR/assets/.
• Entregables finales: PROJECT_DIR/index.html, PROJECT_DIR/detective.json, PROJECT_DIR/analyst.json, PROJECT_DIR/code/*.py, PROJECT_DIR/editor.md, PROJECT_DIR/editor.json, PROJECT_DIR/designer.json, PROJECT_DIR/inspector.json, PROJECT_DIR/viewer.html.