Conectar diseño y datos
Domain Canvas Skill: conectar pantallas, conceptos y diagramas ER
Una pantalla muestra un contrato. La especificación de negocio lo distingue de una solicitud. La base de datos lo relaciona con un cliente y un inmueble. Todo describe el mismo servicio, pero las conexiones se pierden al pasar de un documento a otro. Domain Canvas Skill ofrece a Claude Code un flujo para reunir estas perspectivas en un modelo.
Resulta útil al revisar cambios de una función o asumir el mantenimiento de un sistema: ¿qué representa esta pantalla y dónde está su información? Cambia de vista en la demostración pública para valorar si el enfoque encaja en tu proyecto.
Publicación y revisión del código: 2026-09-15
Un punto de partida para las actualizaciones
Domain Canvas Skill reúne instrucciones y un generador en Python. El flujo examina código y especificaciones del proyecto, organiza pantallas, objetos de negocio y estructuras de datos en model.json y genera un lienzo HTML. Se distribuye como una habilidad de Claude Code instalada en el proyecto, no como un servicio de alojamiento.
La idea central es mantener un modelo compartido en lugar de tres diagramas independientes. Al modificar model.json y regenerar el HTML, cada vista lee los datos actualizados. Las conexiones de las pantallas se guardan en bindings; las relaciones de negocio y de datos, en relationships. Sigue siendo necesario comprobar la coherencia entre las entradas relacionadas.
Tres preguntas sobre el mismo objeto
El dominio comprende objetos y reglas con significado para el negocio, como clientes, solicitudes y contratos. Un diagrama entidad-relación (ER) describe atributos y relaciones de datos. Cambiar de vista permite examinar el mismo objeto con otro nivel de detalle.
| Vista | Qué muestra | Pregunta sobre un contrato |
|---|---|---|
| Diseño (Design) | Pantallas y objetos de negocio que utilizan | ¿Cómo usa el detalle del contrato los datos del cliente, inmueble y documentos? |
| Conceptos (Concept) | Significado de los objetos y relaciones con nombre | ¿Quién contrata qué y qué documentos tiene? |
| ER | Atributos, claves primarias (PK), claves foráneas (FK) y cardinalidades | ¿Qué claves conectan el contrato con el cliente y el inmueble? |
Design no diseña automáticamente una interfaz terminada. Puede mostrar una imagen o un prototipo HTML local; si no existen, usa una vista provisional. Concept muestra descripciones y relaciones; ER añade atributos y marcas de claves. La vista ER actual excluye las líneas kind: domain, que representan relaciones exclusivamente de negocio.
Seguir el ejemplo de CRM inmobiliario
El modelo incluido contiene cinco objetos —cliente, inmueble, solicitud, contrato y documento—, tres pantallas de detalle y cinco relaciones. El detalle del contrato vincula el contrato como objeto principal, cliente e inmueble como contexto y documentos como colección. Una pantalla puede utilizar varios objetos según su función.
Supongamos que quieres mostrar documentos pendientes en el detalle del contrato. Puedes comprobar el vínculo en Design, leer el significado de la relación contrato-documento en Concept e inspeccionar atributos como document.contract_id en ER. Es un ejemplo de revisión propuesto en este artículo; la demostración no detecta documentos pendientes.
En la demostración, cambia entre Design / Concept / ER en la parte superior. Arrastra para desplazarte, usa la rueda o +/− para cambiar el zoom y pulsa Fit para volver a la vista general. Las previsualizaciones son provisionales, no capturas de un CRM en funcionamiento.
Distinguir relaciones confirmadas e inferidas
Cuando una IA organiza un sistema, importa más el fundamento de una línea que su apariencia plausible. La habilidad indica qué fuentes consultar para cada afirmación: esquemas, migraciones y modelos ORM para tablas y claves; especificaciones para el significado de negocio; rutas y componentes para las pantallas.
Las relaciones incluyen confidence: confirmed (confirmada) o inferred (inferida). Concept y ER muestran las inferidas con líneas discontinuas. Las reglas impiden dar por cierta una relación de base de datos solo porque dos conceptos aparecen juntos en una pantalla.
Sin embargo, confirmed es un juicio registrado en el modelo. El generador no lee la evidencia para demostrar su validez. Las fuentes y los supuestos pendientes deben quedar en el README que acompaña al resultado.
Instalar y empezar por un ámbito pequeño
La demostración pública no requiere instalación. Para usarlo en tu proyecto, copia .claude/skills/domain-canvas/ del repositorio a la misma ubicación en el proyecto de destino. Invócalo desde Claude Code:
/domain-canvas contractscontracts es un ejemplo de ámbito. También puedes pedir en lenguaje natural que reúna las pantallas, el modelo conceptual y el diagrama ER de los contratos en un lienzo. Empezar por una función facilita contrastarlo con las fuentes.
.domain-canvas/model.json- Modelo de referencia; actualiza aquí los datos del modelo.
.domain-canvas/index.html- Lienzo generado para consultar.
.domain-canvas/README.md- Fuentes, supuestos pendientes y comando de actualización.
python .claude/skills/domain-canvas/scripts/generate_canvas.py \
--model .domain-canvas/model.json \
--out .domain-canvas/index.htmlEl generador requiere Python 3 y no depende de paquetes Python externos. Ejecuta el comando y abre el HTML en el navegador. Para probar el ejemplo incluido, usa example/model.json como entrada y example/index.html como salida.
Incluye la actualización del modelo, su regeneración y revisión en el proceso de cambio de una función. Modifica el modelo: los cambios directos en el HTML generado desaparecen al regenerarlo. El HTML incorpora el modelo, por lo que conviene comprobar quién puede recibir la estructura interna y los recursos de pantalla antes de compartirlo.
Verificar por separado la coherencia y la corrección del negocio
El generador actual comprueba campos raíz obligatorios, identificadores duplicados de entidades y pantallas, extremos de relaciones y referencias de las pantallas. No valida automáticamente todas las restricciones de la base de datos ni las reglas de negocio.
Por ejemplo, el modelo incluido declara document.contract_id como nullable: true, pero asigna una cardinalidad de 1 al lado del contrato en la relación contrato-documento. Hay que aclarar si un documento puede existir sin contrato o si la relación solo representa documentos ya vinculados. Generar el HTML correctamente no resuelve esa cuestión semántica.
El visor HTML tampoco permite editar o guardar el modelo, escribir cambios en el código o la base de datos ni vigilar continuamente las modificaciones. Omitir tablas de unión técnicas en el modelo conceptual requiere decisiones de modelado: las implementaciones actuales de Concept y ER usan la misma lista de entidades.
Su utilidad práctica es hacer revisables las diferencias de interpretación. Elige una función, construye un modelo con evidencia y revisa las relaciones pendientes con las personas de negocio y desarrollo. Si ese pequeño proceso de mantenimiento es sostenible, el lienzo puede servir como referencia compartida al transferir conocimiento sobre pantallas y datos.
Fuentes y verificación
Se revisaron el README, la definición de la habilidad, las reglas de extracción, el modelo de ejemplo y el generador. La ejecución con el ejemplo produjo HTML con cinco entidades, tres pantallas y cinco relaciones. No se midieron la precisión de extracción en proyectos reales ni la reducción del retrabajo. Los enlaces apuntan al commit inspeccionado; la demostración pública puede actualizarse.
- README: descripción y distribución
- Generador: visualización y validación
- Modelo de CRM inmobiliario
- Reglas de extracción y evidencia
- Definición de la habilidad y flujo de trabajo
GitHub commit: 914d68fe3f12