dsl-design-system

Refina, ajusta o corrige un diseño estratégico DDD ya existente (Paso 1) a partir de feedback humano, nuevas decisiones de negocio o cambios de contexto. También valida, audita y detecta inconsistencias, ambigüedades o errores en el diseño existente, aplicando correcciones automáticas cuando se solicita. Asume dos roles simultáneos: experto de negocio del dominio específico + ingeniero senior de diseño de sistemas DDD. Usar SIEMPRE que el usuario quiera ajustar, corregir, cuestionar, ampliar o validar un diseño del Paso 1 ya generado. Aplica cuando diga frases como "cambia el BC de...", "agrega un BC para...", "quita la integración de...", "en realidad el modelo de negocio es...", "me parece que falta...", "¿por qué separaste...?", "¿no debería ir todo en...?", o cuando proporcione nueva información de negocio que contradiga o amplíe el diseño actual. También aplica cuando diga frases como "valida el diseño", "revisa el sistema", "encuentra inconsistencias", "audita la arquitectura", "¿está correcto el diseño

Paso 1 — Análisis de dominio estratégico (DDD): event storming, clasificación de Bounded Contexts (Core/Supporting/Generic), definición de agregados de nivel estratégico, checklist de entidades candidatas a agregado y revisión de dependencias implícitas por ciclo de vida. Produce los BCs candidatos con su tipo y agregados. Lo ejecuta el subagente `domain-analyst` (Claude) o el orquestador `design-system` inline (Copilot). Para la generación de artefactos ver `ddd-step1-authoring`; para sagas e integraciones ver `ddd-integration-audit`.

Paso 1 — Identificación de sagas por coreografía y Auditoría de Completitud de Integraciones (Matriz A–H), incluida la detección de snapshot-at-write-time (Paso G) y la presentación de Local Read Model vs HTTP síncrono al diseñador (Paso H, con la advertencia OWASP A04 para datos monetarios). Produce las integraciones propuestas y las decisiones LRM/HTTP pendientes. Lo ejecuta el subagente `integration-auditor` (Claude) o el orquestador `design-system` inline (Copilot). El análisis de dominio previo (BCs y agregados) está en `ddd-domain-analysis`.

Ejecuta el Paso 1 del framework de diseño de sistemas con DDD: Diseño Estratégico. Analiza el contexto de negocio ingresado, identifica Bounded Contexts, Agregados y relaciones, y genera los cinco artefactos canónicos: system.yaml, system-spec.md y system-diagram.mmd en arch/system/, más AGENTS.md y CLAUDE.md en la raíz del proyecto. Usar SIEMPRE que el usuario quiera diseñar un nuevo sistema, plataforma, aplicación o dominio de negocio desde cero. También aplica cuando el usuario diga frases como "quiero diseñar", "necesito modelar un sistema", "vamos a hacer el paso 1", "analiza este negocio", "define los bounded contexts", "crea la arquitectura de", o cuando proporcione una descripción de un negocio y pida estructurarla arquitectónicamente. No esperar que el usuario use terminología DDD — si describe un negocio o sistema, este skill debe activarse.

Ejecuta el Paso 2 del framework de diseño de sistemas con DDD: Diseño Táctico de un Bounded Context. Dado un BC ya definido en el Paso 1 (arch/system/system.yaml), genera los seis artefactos canónicos del BC: {bc-name}.yaml, {bc-name}-spec.md, {bc-name}-flows.md, diagrams/, {bc-name}-open-api.yaml y {bc-name}-async-api.yaml en el directorio arch/{bc-name}/. Usar SIEMPRE que el usuario quiera diseñar, detallar o expandir un bounded context específico. Aplica cuando diga frases como "diseña el BC de...", "construye el bounded context de...", "vamos con el paso 2 de...", "detalla el dominio de...", "crea los artefactos de...", "modela el BC de...", o cuando mencione el nombre de un BC existente en el sistema y pida avanzar con su diseño táctico. NO diseñar ningún BC que no esté definido en arch/system/system.yaml — validar siempre antes de comenzar.

Refina, ajusta o corrige los artefactos del diseño táctico DDD (Paso 2) de un Bounded Context ya diseñado. También valida a profundidad la coherencia interna del BC y su alineación con arch/system/. Asume dos roles simultáneos: experto de negocio del dominio específico + ingeniero senior de diseño de sistemas DDD. Usar SIEMPRE que el usuario quiera ajustar, corregir, cuestionar, ampliar o validar el diseño táctico de un BC ya generado. Aplica cuando diga frases como "cambia el agregado de...", "agrega una entidad a...", "refina el BC de...", "el dominio de [BC] está mal...", "agrega un caso de uso...", "la regla de negocio no es así...", "cambia el flujo de...", "ajusta el contrato de...", "¿por qué modelaste X como entidad?", "esto debería ser un VO", "falta una regla en...", "valida el diseño de [BC]", "¿está coherente el BC?", "encuentra inconsistencias en...", "audita el diseño táctico", "¿es correcto el modelo de dominio?", o cualquier variante de revisión, cuestionamiento o ajuste sobre artefactos en ar

Diseña el dominio táctico completo de un Bounded Context (Paso 2) y luego valida automáticamente la coherencia interna del BC y su alineación con arch/system/ usando el skill de refinamiento. Úsalo cuando quieras diseñar o refinar el dominio táctico de un BC: ingresa el nombre del BC y el agente produce los seis artefactos canónicos (bc.yaml, bc-spec.md, bc-flows.md, bc-open-api.yaml, bc-async-api.yaml, diagrams/) más un informe de validación con correcciones aplicadas.

Diseña un sistema completo con DDD Paso 1 (Diseño Estratégico) y luego valida automáticamente la correcta elección de agregados, entidades e integraciones usando el skill de refinamiento. Úsalo cuando quieras diseñar un nuevo sistema desde cero: ingresa el contexto del negocio y el agente produce los cinco artefactos canónicos (system.yaml, system-spec.md, system-diagram.mmd, AGENTS.md, CLAUDE.md) más un informe de validación con correcciones aplicadas.