La vitrina · Ficha técnica
- Sellada
- Sellada el 2026-06-30
- Fase 4
- 0 sprints
- v1.1.0
- Datos del 2026-09-06
Constructor de Tableros Power BI
De un texto de requerimientos a un tablero que ya pasó su prueba.
- Claude Code
- powerbi-modeling-mcp
- Skill propia autoria-pbir
- validate_pbir.py
- DAX (EVALUATE)
- PBIP y PBIR
- Power BI Desktop
- Markdown con frontmatter
Qué no hace nadie más
Escribe el reporte en el JSON nativo de Power BI con una skill propia, sin CLI ni ecosistema Fabric, y nunca toca el modelo a mano: eso es del MCP. Ninguna corrida cierra sin DAX en verde, validador limpio y render aprobado por una persona.
20
Criterios binarios de aceptación
medido5
Gates de aprobación humana
medido1
Tableros construidos
medido33
Dashboards de referencia
medido691,2h/año
Horas liberadas al año, escenario base
estimación
Para quién, y qué resuelve
La persona antes que la tecnología.
Para quién
Para quien construye tableros de Power BI por encargo y hoy los arma a mano: leer el requerimiento, inventar las medidas DAX, arrastrar cada visual, y repetirlo en el tablero siguiente sin que lo aprendido quede en ninguna parte. Cada tablero le cuesta del orden de treinta y dos horas, y el ritmo que quisiera sostener es de tres al mes.
La promesa
Le entrega dos cosas: los requerimientos en texto y un proyecto con las tablas. El harness diagnostica el modelo, propone la lista de medidas, columnas y relaciones para que la apruebe, la crea por el MCP probando cada medida, y después escribe el reporte entero en el formato nativo. Él revisa el render y aprueba el refresh; lo aprendido queda escrito para la corrida siguiente.
Cómo funciona
El proceso en BPMN: un carril por actor, la decisión donde se decide, y el bucle a la vista.
- El diagnóstico muestrea el dato real y convierte los requerimientos en indicadores medibles antes de decidir un solo visual.
- Nada se crea sin esa lista aprobada, y el modelo semántico no se edita a mano nunca: solo el MCP lo toca.
- Cada medida se prueba contra el modelo vivo. Tres reintentos fallidos y la corrida se detiene y escala al autor.
- El validador corre local: capa estructural siempre, capa de schemas oficiales cuando hay red. Sin errores, no hay render.
- No hay computer-use: cómo se ve lo confirma una persona en Power BI Desktop, y ese paso no se puede automatizar.
- Los aprendizajes quedan en la bitácora de patrones y se leen al abrir la corrida siguiente: no se reutilizan componentes, sino decisiones.
Desliza para ver el proceso completo.
Proceso declarado por la propia app en su export.
Qué tiene
9 grupos · 79 funcionalidades.
El pipeline de seis fases
6 funcionalidades
Intake, diagnóstico, diseño, backend, frontend y cierre. Una corrida, un tablero.
El modelo, por el MCP
Relaciones, columnas, medidas y RLS, cada una probada antes de seguir.
La skill de autoría del reporte
11 funcionalidades
Once referencias por tipo de visual, un validador propio y un tema base.
Los gates de aprobación
5 funcionalidades
Modelo, visuales, refresh, override y publicación: cinco puntos de freno.
Work-items con criterio binario
8 funcionalidades
Ocho entregables y veinte casillas que se marcan o no se marcan.
Contexto y cápsulas de dominio
8 funcionalidades
Cuatro capas de contexto y cuatro cápsulas: DAX, trampas del formato, archetypes, fallback.
La memoria entre corridas
7 funcionalidades
Seis plantillas de corrida y una bitácora de patrones que se lee al empezar.
El catálogo de diseño
33 funcionalidades
Treinta y tres tableros de referencia, indexados por archetype y audiencia.
Los tableros, versionados
1 funcionalidades
Los proyectos viven en el repo: se crean y se mantienen, corrida a corrida.
Límites, y lo que nunca hace
Lo que decidió no ser vale tanto como lo que es.
Límites, a propósito
- Construye desde cero: migrar un tablero entre fuentes de datos queda fuera de alcance, y será otro harness.
- Entrega un proyecto local versionado en git; publicar al servicio en la nube está diferido y no forma parte del harness.
- No ve la pantalla: sin computer-use, cómo se ve el tablero lo confirma una persona en Power BI Desktop.
- El retorno es una estimación con supuestos declarados, no horas cronometradas: aún no hay corrida medida contra la línea base.
Nunca
- Edita el modelo semántico a mano: relaciones, medidas, columnas y RLS pasan solo por el MCP de modelado.
- Crea una medida, columna o relación antes de que su lista quede aprobada.
- Declara cerrada una corrida sin DAX en verde, validador sin errores y render revisado.
- Inventa cifras de valor: cada supuesto del retorno lleva su fuente y su nivel de confianza.
- Traslada archivos con datos cacheados entre la máquina de empresa y la personal sin autorización.
Dónde está
La versión anclada, no el tiempo real.
- Fase 4ciclo
- 8work-items definidos
- 2026-06-30sellada (gate de pruebas)
- v1.1.0versión del repo
- 5decisiones registradas
Aquí se muestra; no se entrega.