analyze

name	analyze
description	Análisis completo de datos BI/BA — descubrimiento de dominio, EDA y calidad de datos, planificación de métricas y KPIs con framework analítico, queries de datos vía MCP, análisis Python con pandas, visualizaciones, generación de informes multi-formato (PDF, DOCX, PowerPoint, Dashboard web, Informe web/Artículo web, Póster/Infografía, Excel/XLSX) y documentación del razonamiento. Usar cuando el usuario necesite analizar datos de negocio, calcular KPIs, producir visualizaciones, generar resúmenes gráficos, obtener insights o responder preguntas analíticas sobre dominios gobernados. También se activa para comparaciones multi-métrica, resúmenes de KPIs, peticiones de entregables (informes, dashboards, libros) o cualquier petición que requiera cruzar datos entre dimensiones.
argument-hint	[pregunta o tema de análisis]

Skill: Análisis BI/BA Completo

Esta guía define el workflow completo para realizar un análisis de Business Intelligence / Business Analytics.

1. Parsear la Petición

• Extraer la pregunta de negocio principal del argumento: $ARGUMENTS
• Identificar sub-preguntas implicitas
• Detectar si menciona un dominio, tablas o métricas específicas
• Detectar si menciona un formato de salida preferido

1.1 Triage rápido

Si la petición se resuelve con una sola llamada MCP (ver Fase 0 del workflow (AGENTS.md)), responder directamente:

• Definiciones/conceptos → search_domain_knowledge → chat
• Estructura/columnas → list_domain_tables / get_table_columns_details → chat
• Dato puntual → query_data → chat
• En estos casos, NO continuar con el resto del workflow

Si la petición requiere análisis (cruce de datos, hipótesis, visualizaciones, múltiples métricas), continuar con sección 2.

2. Descubrimiento de Dominio

Si el dominio ya es conocido de la conversación (identificado y explorado en turnos previos), saltar esta sección y continuar con la sección 3. Usar el contexto de dominio y tablas ya establecido.

Leer y seguir guides/stratio-data-tools.md sec 5 para los pasos de descubrimiento del dominio (buscar o listar dominios, seleccionar, explorar tablas, columnas y terminología).

3. EDA y Perfilado de Datos

Antes de preguntar al usuario sobre formatos y planificar métricas, entender la realidad de los datos en dos dimensiones complementarias: el perfil estadístico (EDA) y la cobertura de calidad de gobernanza ya definida para esas tablas. Ambas se lanzan en paralelo. Los marcadores estadísticos del EDA vienen de profile_data (y, cuando se necesita un agregado concreto, de una query MCP agregada) — nunca de descargar las filas de las tablas para calcularlos en pandas; sigue la jerarquía de 3 niveles de guides/stratio-data-tools.md §3.

1. Lanzamiento en paralelo — Para las tablas clave identificadas en el paso 2, lanzar a la vez:

   • profile_data por tabla (perfilado estadístico — seguir la mecánica y umbrales adaptativos de guides/stratio-data-tools.md sec 6)
   • get_tables_quality_details(domain_name, [tablas]) (reglas de gobernanza existentes y su estado OK/KO/WARNING)

2. Evaluar perfil estadístico (de profile_data):

   • Completitud: % de nulos por columna. Marcar columnas con >50% nulos como limitación
   • Rango temporal: Verificar que los datos cubren el periodo que el usuario necesita
   • Outliers: Identificar valores extremos (IQR) que podrían sesgar promedios o totales
   • Distribuciones: Sesgo en numéricas, desbalanceo en categóricas
   • Correlaciones: Relaciones fuertes entre variables (|r| > 0.7) — pueden indicar multicolinealidad o redundancia
   • Cardinalidad: Categóricas con >100 valores únicos son difíciles de visualizar o agrupar

3. Evaluar cobertura de calidad de gobernanza (de get_tables_quality_details):

   • Contar reglas por tabla y en total
   • Clasificar por estado: OK, KO, WARNING, sin ejecutar
   • Para cada regla KO/WARNING, anotar la dimensión y la columna afectada
   • Identificar si alguna regla KO/WARNING afecta a una columna que el usuario va a usar para métricas, dimensiones o filtros en su petición
   • Este es un chequeo ligero: una evaluación completa de cobertura (catálogo de dimensiones, identificación de gaps, priorización) está fuera del alcance de esta skill. Si el usuario pide explícitamente una evaluación completa de cobertura en lugar de un análisis, parar aquí e indicarle que se requiere un flujo dedicado — el agente hará el routing según sus instrucciones

4. Checklist de suficiencia — Aplicar ANTES de preguntar formatos:

   Criterio	Umbral mínimo	Si falla
   Registros	>0	STOP — reformular query
   Completitud temporal	≥80% del periodo pedido	Ofrecer análisis del periodo disponible
   Nulos en vars clave	<30%	Alertar limitación severa, considerar imputación
   Tamaño para inferencia	n ≥ 30	Reportar como exploratorio, sin tests estadísticos
   Tamaño para clustering	n ≥ 10 × features	Recomendar análisis descriptivo sin segmentación
   Variabilidad	std > 0 en numéricas clave	Excluir variable constante
   Granularidad	Nivel pedido disponible	Ofrecer agregacion al disponible

5. Data Profiling Score: ALTO (80-100%), MEDIO (60-79%), BAJO (<60%) — derivado del perfil estadístico. Si BAJO, recomendar mejorar datos o reformular.

6. Governance Quality Status: Resumen derivado de get_tables_quality_details. Formato: <N reglas definidas, X OK, Y KO, Z WARNING> o sin reglas de calidad definidas para estas tablas. Si alguna regla KO/WARNING afecta a una columna relevante, marcarla con un ⚠️.

7. Informar al usuario: Generar mini-resumen combinado con ambas señales antes de preguntar sobre formato y estilo. Ejemplos:

   • "Perfilado: ALTO (85%) · Los datos cubren de enero 2023 a diciembre 2025. La columna descuento tiene 35% de nulos. 12 outliers en importe_total (>3 IQR). La distribución de categoria_producto está concentrada: 3 de 15 categorías representan el 80% de registros. Gobernanza: 8 reglas definidas (6 OK, 1 KO, 1 WARNING). ⚠️ La regla KO validez-fecha_factura afecta a una columna que vas a usar para agregación temporal — tomar los resultados de esa dimensión con cautela."
   • "Perfilado: MEDIO (72%) · 30% nulos en importe, hueco de 3 meses en Q2 2024. Gobernanza: sin reglas de calidad definidas para estas tablas — el perfil estadístico es tu única señal de calidad."
   • "Perfilado: ALTO (90%) · sin issues significativos. Gobernanza: 5 reglas definidas, todas OK."

8. Ajustar expectativas: Si hay limitaciones serias (Data Profiling Score BAJO, reglas KO sobre columnas clave, cobertura temporal incompleta), advertir al usuario. Cuando una regla KO afecte a una columna central a la petición, preguntar si quiere:

   • Continuar el análisis dejando constancia de la limitación en el deliverable
   • Excluir esa columna/dimensión
   • Parar el análisis y solicitar una evaluación completa de cobertura (flujo dedicado fuera del alcance de esta skill)

4. Clasificación y Preguntas al Usuario

Nota: Todas las preguntas con opciones de esta sección siguen la convención de preguntas.

4.0 Triage vs Análisis

Las preguntas simples (datos puntuales, sin dimensiones de corte) se resuelven en Triage (Fase 0 del workflow) sin invocar esta skill. Todo lo demás es un análisis y sigue el flujo de bloques de preguntas descrito a continuación.

4.1 Bloque de preguntas — Profundidad, Audiencia, Formato, Tests

Una sola interacción:

#	Pregunta	Opciones (literales)	Selección	Condicion
1	¿Qué profundidad de análisis prefieres?	Rápido · Estándar (Recomendado) · Profundo	Única	Siempre
2	¿Para que audiencia es el análisis?	C-level/Direccion · Manager/Responsable · Equipo técnico/Data · Mixta/General	Única	Siempre
3	¿En que formatos quieres los deliverables?	PDF · DOCX · PowerPoint (.pptx) · Dashboard web (HTML interactivo con Plotly) · Informe web / Artículo web (página HTML autocontenida, narrativa o editorial) · Póster/Infografía (visual de una página) · Excel (libro .xlsx)	Múltiple	Siempre
4	¿Quieres que se generen y ejecuten tests unitarios sobre el código Python?	Sí (Recomendado): mejora precisión y calidad, pero consume más tiempo, coste y contexto · No: ejecución directa sin tests	Única	Solo Estándar/Profundo

Regla adaptativa: Si la petición del usuario ya especifica información que responde a alguna de estas preguntas, pre-rellenar esa respuesta y no volver a preguntarla. Por ejemplo: si el usuario dijo "dame un informe en PDF", pre-rellenar formato como Document; si dijo "análisis rápido", pre-rellenar profundidad como Quick; si dijo "dashboard ejecutivo", pre-rellenar audiencia como C-level/Executive y formato como Web. Solo preguntar aquello cuya respuesta no pueda inferirse de la petición.

• Los tests validan transformaciones y cálculos antes de ejecutar con datos reales. Mejoran la precisión pero consumen más tokens, tiempo y coste. En profundidad Rápido, testing se desactiva automáticamente sin preguntar al usuario.
• La pregunta de formato SIEMPRE permite selección múltiple
• Las opciones de formato son EXACTAMENTE 7: PDF, DOCX, PowerPoint, Dashboard web, Informe web/Artículo web, Póster/Infografía, Excel. Cada una enruta a su skill writer dedicada (ver instrucciones del agente §8). No inventar, no omitir, no sustituir
• Si no selecciona formato → no hay deliverables, el análisis se entrega solo en chat + report.md automático
• Si selecciona uno o más formatos → los deliverables SE GENERAN SIEMPRE, independientemente de la profundidad elegida. Rápido/Estándar/Profundo afecta al análisis, no a los entregables.
• Requisitos adicionales vía opción "Other" (filtros temporales, segmentos, métricas obligatorias)

La estructura por defecto es el scaffold analítico (resumen ejecutivo → metodología → datos → análisis → conclusiones). Si el usuario señala "estructura libre", "rompe el molde" o similar, las skills writer operan con plena libertad. La identidad visual se propone como un ítem dentro del plan (§5.11), no se pregunta aquí — ver las instrucciones del agente §8.3 para la cascada de branding.

5. Planificación

Elaborar un plan detallado siguiendo el framework analítico (sec "Framework Analítico" de AGENTS.md):

5.1 Librerias adicionales

Evaluar si requirements.txt necesita ampliarse

5.2 Enfoque analítico: descriptivo, segmentación o feature importance

Determinar si la pregunta requiere solo análisis descriptivo o también segmentación/clustering o feature importance:

Escenario	Recomendación
Describir que paso y por qué	Análisis descriptivo (pandas, agrupaciones, comparativas)
Descubrir grupos/segmentos no predefinidos	Clustering (RFM, KMeans, DBSCAN). Ver clustering-guide.md
Identificar factores influyentes (>5 variables)	Feature importance exploratoria. Ver clustering-guide.md sec 7
Proyección temporal	Proyección lineal + IC95%. Ver advanced-analytics.md

Detección automática: Si la pregunta menciona "segmentar", "agrupar", "perfiles" → clustering. Si menciona "que factores influyen", "que explica" → feature importance. Si pide proyección temporal → proyección lineal (no ML). Inferir el tipo de la pregunta y los datos, no preguntar al usuario.

5.3 Hipótesis

Formular hipótesis ANTES de consultar datos. Usar la plantilla de sec "Pensamiento analítico" de AGENTS.md. Para cada sub-pregunta identificada en el paso 1:

• Que esperamos encontrar y por que
• Que resultado seria sorprendente
• Documentar las hipótesis en el plan para validarlas luego con datos

Ejemplo completo:

### H1: Ventas Q4 ≥30% superiores al promedio Q1-Q3 por estacionalidad retail
- Enunciado: El ratio ventas_Q4 / promedio(ventas_Q1-Q3) es ≥ 1.30
- Fundamento: Pico estacional observado en nov-dic durante EDA
- Cómo validar: query "ventas totales por trimestre del último año"
- Criterio: ratio ≥ 1.30
→ Resultado: CONFIRMADA (ratio = 1.45)
→ Evidencia: Q4 = €2.1M vs promedio Q1-Q3 = €1.45M
→ So What: Q4 = 36% ventas anuales. Ajustar inventario desde oct, reforzar logística nov
→ Confianza: Alta (3 años de datos, patrón consistente)

5.4 Métricas y KPIs

Para cada KPI, documentar:

Campo	Descripción
Nombre	Identificador claro
Fórmula	Cálculo exacto
Granularidad	Temporal: diario/semanal/mensual/trimestral
Dimensiones	Ejes de corte (región, producto, segmento)
Benchmark	Objetivo, media del sector, o periodo anterior
Fuente	Tabla(s) y columna(s) del dominio
Test estadístico	Si requiere IC o comparación entre grupos (ver advanced-analytics.md)

Benchmark Discovery — Escala según profundidad (ver matriz de activación en AGENTS.md sec 2):

• Rápido: No buscar activamente. Usar comparación temporal natural si la query ya incluye dimensión tiempo
• Estándar: Best-effort silencioso:
  1. search_domain_knowledge("target/objetivo de [nombre_KPI]", domain)
  2. Query MCP adicional para mismo KPI en periodo T-1
  3. Si no hay referencia externa: media/mediana como referencia interna Sin benchmark → reportar el dato normalmente, documentar en reasoning
• Profundo: Pasos 1-3 + tendencia si >6 puntos temporales + preguntar al usuario

Documentar el benchmark en el campo "Benchmark" del KPI. Los datos sin benchmark se reportan con normalidad — la ausencia solo se marca como limitación en profundidad Profundo.

5.5 Preguntas de datos

Lista de preguntas en lenguaje natural para query_data. NUNCA escribir SQL.

Para buenas prácticas de formulación y estrategia de queries (orden de planificación, ejecución en paralelo), ver guides/stratio-data-tools.md sec 11.

5.6 Visualizaciones

Leer y seguir visualization.md para selección de gráficas y principios de visualización.

Para cada visualización del plan, definir:

• Pregunta analítica que responde
• Tipo de gráfica: Seleccionar según tabla en visualization.md sec 1
• Variables: Que va en cada eje, agrupaciones, filtros
• Título: Formulado como insight, no como descripción
• Datos fuente: Query MCP que alimenta la visualización

5.7 Técnicas analíticas avanzadas

Activar según la profundidad seleccionada (ver matriz de activación en AGENTS.md sec 2):

• Estándar: Consultar advanced-analytics.md cuando sea relevante
• Profundo: Consultar advanced-analytics.md sistemáticamente

Cubre: rigor estadístico (tests, IC, effect sizes), análisis prospectivo (escenarios, Monte Carlo), root cause analysis, detección de anomalías.

5.8 Patrones analíticos adicionales

Implementación detallada de patrones cuyo trigger está en sec "Patrones analíticos operacionalizados" de AGENTS.md (Lorenz/Gini, mix, indexación, desviación vs referencia, gap).

Cuando un patrón se active: consultar analytical-patterns.md para query MCP, Python e interpretación.

5.9 Segmentación y clustering

Para guía completa de segmentación (RFM, clustering, validación, profiling), ver clustering-guide.md.

Usar cuando el usuario pida segmentación, agrupación de clientes/productos, o descubrimiento de perfiles. La guía cubre:

• Tabla de decisión (cuando usar rule-based, RFM, KMeans o DBSCAN)
• RFM con quintiles y etiquetas de negocio
• Clustering básico con elbow + silhouette
• Validación de clusters y profiling obligatorio

Para feature importance como complemento a la segmentación o al análisis descriptivo, ver clustering-guide.md sec 7.

5.10 Estructura del deliverable

Secciones, contenido de cada una, formato. Aplicar principios de data storytelling (sección 7.1)

5.11 Presentar plan

Presentar plan completo al usuario y solicitar aprobación antes de ejecutar.

Identidad visual (solo cuando al menos un formato visual fue seleccionado en §4.1): incluir como ítem en el plan un tema propuesto con alternativos y descartados, siguiendo la cascada de branding en las instrucciones del agente §8.3. Formato:

Identidad visual:

• Elegido: <tema> — <por qué encaja en este contexto, una línea corta>.
• Alternativos cercanos: <tema_a>, <tema_b>.
• Descartados: los demás (<razón agrupada>).

El usuario aprueba el plan completo o corrige el tema en el mismo turno. Si no se seleccionaron formatos, saltarse este ítem entero. Si la cascada se resolvió silenciosamente (niveles 1-4 de §8.3), ocultar el ítem o mostrar una línea corta indicando qué tema se aplicó y por qué — a discreción del agente según ayude o no a la revisión del usuario.

Disclosure de la guía de dashboard (solo cuando se seleccionó Dashboard web): incluir una línea corta indicando si la guía analítica de dashboard se aplicará. Ejemplo:

Dashboard aplicará el patrón analítico estándar (KPIs, filtros, tablas ordenables). Si prefieres algo más libre o narrativo, avísame.

Si el usuario señaló libertad de diseño en el brief, indicarlo: "Dashboard NO aplicará la guía estándar porque pediste diseño libre."

Al final de la presentación del plan, incluir una nota breve:

Si dispones de documentación adicional, benchmarks de referencia, informes previos o datos complementarios que puedan enriquecer el análisis, puedes compartirlos ahora.

No convertir esta nota en pregunta bloqueante. Es una invitación, no un paso obligatorio. Si el usuario no aporta nada, continuar sin esperar respuesta adicional más allá de la aprobación del plan.

6. Ejecución

6.0 Determinar carpeta del análisis

Generar nombre YYYY-MM-DD_HHMM_nombre_descriptivo (minusculas, sin tildes, guiones bajos, max 30 chars en el nombre). Declarar en chat. Crear subdirectorios: output/[ANALISIS_DIR]/scripts/, output/[ANALISIS_DIR]/data/, output/[ANALISIS_DIR]/assets/. Si profundidad >= Estándar, crear también output/[ANALISIS_DIR]/reasoning/ y output/[ANALISIS_DIR]/validation/.

Persistir el plan aprobado en output/[ANALISIS_DIR]/plan.md. Escribir el plan tal como fue formulado en la Fase 3 (sección 5) y aprobado por el usuario: hipótesis, métricas/KPIs, queries de datos, visualizaciones, estructura del deliverable, complejidad, profundidad, formatos y estilo.

6.1 Entorno

El stack Python lo provee el entorno (imagen del sandbox Cowork o venv local); python3 resuelve automáticamente. Si el análisis necesita una librería no incluida en requirements.txt, pip install <pkg> en el entorno actual. Para deps recurrentes, añadirlas también a requirements.txt para que la imagen del sandbox las recoja en el siguiente rebuild.

6.2 Obtención de datos

• Prefiere resultados agregados. Pide al MCP las métricas/marcadores ya calculados (medias, percentiles, conteos, correlaciones por grupo) para que cada resultado sean unas pocas filas. Sigue la jerarquía de 3 niveles de guides/stratio-data-tools.md §3: agregar en el MCP (query_data, o generate_sql+execute_sql) → profile_data para los marcadores del EDA → detalle fila a fila solo cuando un test/clustering realmente lo necesite
• Usar query_data(data_question=..., domain_name=..., output_format="dict") para cada pregunta de datos. Lanzar en paralelo todas las queries independientes definidas en el plan (paso 5.5). Solo serializar si una query necesita el resultado de otra para formularse
• Seguir todas las reglas de guides/stratio-data-tools.md (MCP-first, output_format, no SQL manual, ejecución en paralelo)
• El detalle fila a fila se queda fuera del contexto. Cuando una query devuelve legítimamente detalle fila a fila para un test/clustering en Python y el payload es grande, el runtime anfitrión lo trunca a un fichero (guides/stratio-mcp-response-patterns.md §2, rama "datos-para-cálculo"): haz que el script lea ese fichero (json.load(ruta) → pd.DataFrame(resp["data"])). Guardar datos intermedios en output/[ANALISIS_DIR]/data/ como CSV para scripts posteriores. Nunca pegues el payload de detalle en el chat

6.3 Validación post-query (obligatorio)

Aplicar las 7 validaciones de guides/stratio-data-tools.md sec 8 a cada resultado recibido. Cuando se lanzan queries en paralelo, validar cada resultado conforme llega. Si alguna falla: reformular la pregunta al MCP, informar al usuario, ajustar el plan.

6.4 Desarrollo de scripts

• Escribir scripts en output/[ANALISIS_DIR]/scripts/ con nombres descriptivos que incluyan contexto del análisis
• Cada script debe:
  • Leer datos de output/[ANALISIS_DIR]/data/ (CSVs guardados previamente) o recibir datos como parámetro
  • Realizar transformaciones y cálculos
  • Generar visualizaciones en output/[ANALISIS_DIR]/assets/
  • Producir outputs en output/[ANALISIS_DIR]/
• Datasets grandes (>100k filas): Usar muestreo estratificado para desarrollo rápido. Para la versión final, preferir agregar en el MCP (SQL) para que solo el resultado agregado llegue al análisis; si el script realmente necesita el detalle fila a fila completo, leerlo del disco (el fichero de salida truncada o un CSV guardado), nunca de un payload pegado en el contexto

6.5 Testing

Solo si la profundidad es Estándar/Profundo Y el usuario eligió "Sí" en la pregunta de testing de §4.1. En profundidad Rápido o si el usuario eligió "No", omitir esta sección y ejecutar directamente el script con datos reales.

• Generar output/[ANALISIS_DIR]/scripts/test_*.py con tests unitarios ANTES de ejecutar con datos reales
• Usar DataFrames mock con estructura similar a los datos reales
• Validar transformaciones, cálculos y formatos de salida
• Ejecutar: python3 -m pytest output/[ANALISIS_DIR]/scripts/test_*.py -v
• Solo proceder si los tests pasan

6.6 Ejecución con datos reales

python3 output/[ANALISIS_DIR]/scripts/mi_script.py

6.7 Loop de iteración

Tras revisar resultados iniciales, evaluar si requieren iteración:

1. Trigger: Hallazgo contradice hipótesis, patrón inesperado, o pregunta crítica no prevista
2. Acción: Documentar hallazgo → formular nueva(s) pregunta(s) → queries MCP adicionales (6.2-6.3) → actualizar scripts
3. Limite: Max 2 iteraciones. Más → documentar como análisis de seguimiento
4. Registro: Cada iteración en reasoning: hipótesis → hallazgo → nueva hipótesis → resultado

6.8 Complexity Upgrade

Si durante la ejecución se detecta un hallazgo que excede el alcance del nivel de complejidad actual:

Triggers:

• Anomalía: resultado difiere >30% del benchmark o de lo razonable para el dominio
• Inconsistencia: dos queries dan totales que no cuadran (diferencia >5%)
• Patrón crítico: concentración Gini >0.8, caida/crecimiento >50% interperiodo, outlier en KPI principal

Acción:

1. Pausar la ejecución normal
2. Informar al usuario siguiendo la convención de preguntas: "He detectado [descripción del hallazgo]. Esto requiere investigación adicional. ¿Quieres que profundice?" con opciones:
   • "Sí, profundizar" → Escalar complejidad, activar fases adicionales (EDA completo, hipótesis sobre el hallazgo, visualizaciones de drill-down)
   • "No, solo documentar" → Registrar hallazgo en el chat y en reasoning como "área de investigación futura"
3. El upgrade NO reinicia el análisis — extiende el análisis actual con fases adicionales

Diferencia con el loop de iteración (6.7): El loop refina hipótesis dentro del mismo nivel de complejidad. El upgrade cambia el nivel (ej: Triage → Análisis) y activa capacidades adicionales (EDA, hipótesis formales, visualizaciones).

6.9 Generación de deliverables

OBLIGATORIO si el usuario seleccionó formatos en §4.1. La profundidad NO afecta a este paso.

1. Tokens de marca (una vez, antes de cualquier formato visual): cargar brand-kit y resolver el bundle de tokens del tema fijado en el plan aprobado (§5.11). El tema se decidió según la cascada de branding del agente (§8.3) — aquí solo lees su definición para que las skills writer siguientes apliquen una paleta coherente. Si el usuario corrigió el tema al aprobar el plan, usa el corregido. Los mismos tokens aplican a cada entregable posterior, así que todo el análisis se mantiene visualmente coherente.
2. Para cada formato seleccionado, cargar su skill writer dedicada y producir el entregable. El entregable debe incorporar el contenido analítico (report.md, gráficas de assets/, tablas), aplicar los tokens de marca del paso 1 y estar redactado en el idioma del usuario:
   • PDF → pdf-writer. Salida: <slug>-report.pdf.
   • DOCX → docx-writer. Salida: <slug>-report.docx.
   • PowerPoint → pptx-writer. 16:9 por defecto; 4:3 solo si el usuario lo pidió explícitamente. Salida: <slug>-presentation.pptx.
   • Dashboard web → web-craft. También cargar analytical-dashboard.md (de esta misma carpeta de skill) como input a web-craft, SALVO que el usuario señalara libertad de diseño al aprobar el plan (disclosure de §5.11). Salida: <slug>-dashboard.html.
   • Informe web / Artículo web → web-craft. NO cargar analytical-dashboard.md. Usar artifact class Page o Article. Layout: secciones narrativas, callouts KPI inline, figuras Plotly incrustadas como figuras estáticas, filtros mínimos o ninguno. Salida: <slug>-article.html.
   • Póster/Infografía → canvas-craft. Salida: <slug>-poster.pdf o <slug>-poster.png.
   • Excel → xlsx-writer. Composición analítica según xlsx-writer SKILL.md §8: hoja cover/KPI con 3-4 métricas clave del resumen ejecutivo, hoja de parámetros documentando filtros / rango de fechas / selecciones de segmento, hojas de detalle (una por dimensión principal) con openpyxl.worksheet.table.Table objects y formato condicional en columnas de delta (vs período anterior / benchmark / target), hoja opcional de validación de hipótesis en profundidad Standard/Deep, apéndice opcional de raw data cuando el dataset sea pequeño. Si el libro usa fórmulas, cargar /xlsx-writer y ejecutar su scripts/refresh_formulas.py <ruta> --json post-build para poblar los valores cacheados. Salida: <slug>-workbook.xlsx.
3. Escribir output/[ANALISIS_DIR]/report.md (tablas + mermaid) como documentación interna, siempre — independientemente de los formatos seleccionados. Es la fuente de verdad que consumen las skills writer.
4. Convención de nombres: <slug> = parte descriptiva de [ANALISIS_DIR] (todo lo que va después de YYYY-MM-DD_HHMM_). Los ficheros internos (plan.md, reasoning/, validation/) se quedan sin prefijo.
5. Verificar cada fichero en disco con ls -lh output/[ANALISIS_DIR]/ una vez producido el entregable. Regenerar si falta ANTES de reportar al usuario.

6.10 Reasoning

Generar reasoning según la profundidad (ver defaults en sec "Reasoning" de AGENTS.md):

• Rápido: No generar fichero. Las notas clave se incluyen en el reporte del chat (sec 7.1).
• Estándar/Profundo: Seguir la guía completa en reasoning-guide.md. Generar solo .md.

Si el usuario pide el reasoning en otro formato, enrutar a la skill correspondiente según el contrato formato→skill del agente (§8); reasoning.md es la fuente de contenido. brand-kit NO aplica al reasoning — documentación interna. Registrar el tema aplicado (si se usó alguno para entregables visuales en este análisis) como línea dentro de reasoning.md: theme applied: <nombre>.

6.11 Validación de output final

Ejecutar validación según la profundidad (ver defaults en sec "Reasoning" de AGENTS.md):

• Rápido: Solo Bloque A (integridad de archivos). Reportar resultado en chat. No generar fichero.
• Estándar: Bloques A + B + C. Generar validation/validation.md. Reportar resumen en chat.
• Profundo: Bloques A + B + C + D. Generar validation/validation.md. Reportar resumen en chat.

Para detalle de cada bloque, umbrales y criterios PASS/WARNING/FAIL, ver validation-guide.md.

Si el usuario pide la validación en otro formato, enrutar a la skill correspondiente según el contrato formato→skill del agente (§8); validation.md es la fuente de contenido. brand-kit NO aplica a la validación — documentación interna.

7. Reporte Final

7.1 Estructura del reporte en chat

Al presentar hallazgos en la conversación, seguir esta estructura:

1. Hook: El hallazgo más impactante primero
2. Resumen ejecutivo (3-5 bullets con "so what")
3. Insights con datos concretos y contexto comparativo (vs anterior, vs objetivo)
4. Recomendaciones accionables priorizadas (alto impacto + alta confianza primero)
5. Limitaciones y caveats
6. Rutas de archivos generados
7. Sugerencias de análisis de seguimiento

Checklist "So What?" obligatorio — Para CADA hallazgo antes de incluirlo:

Pregunta	Malo (dato)	Bueno (insight accionable)
Magnitud?	"Las ventas bajaron"	"Bajaron 12%, ≈€45K/mes"
Vs. qué?	"Norte va bien"	"Norte +23% vs media nacional, +8% vs target"
Qué hacer?	"Mejorar retención"	"Programa fidelización en Premium (45% vs 72% benchmark) → ROI €120K/año"
Confianza?	"Clientes prefieren A"	Adaptar a profundidad: Rápido="67% (n=450, Alta)"; Estándar="67% (n=450, IC95%: 62-72%)"; Profundo="67% (n=450, IC95%: 62-72%, p<0.001)"

Si un hallazgo no pasa las 4 preguntas → es información, no insight. No va al resumen ejecutivo.

Clasificación de insights — Determina ubicación en el reporte:

• CRITICO: Alto impacto + alta confianza → Resumen ejecutivo, recomendación firme
• IMPORTANTE: Alto impacto + baja confianza → Sección principal, investigar más
• INFORMATIVO: Bajo impacto → Apéndice, sin recomendación

Para principios de data storytelling y mapping hallazgos → narrativa, leer visualization.md secciones 3 y 4.

8. Propuesta de Conocimiento (Opcional)

Tras presentar el reporte final, preguntar al usuario siguiendo la convención de preguntas:

• Si: Analizar conversación y proponer conocimiento al dominio
• No: Finalizar sin proponer

Si acepta, cargar la skill propose-knowledge con el dominio usado en este análisis. Si rechaza, finalizar normalmente.

Este paso es SIEMPRE opcional. Nunca proponer automáticamente.