asuridev

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.

Valida end-to-end TODOS los escenarios (A, B, C…) de los flujos `FL-{BC}-{N}` de `{bc}-flows.md` contra la aplicación corriendo y la infraestructura real (DB, cache, broker, storage): ejecuta la request de cada escenario y verifica el status y los side effects esperados (o su ausencia). Opera en dos modos: `validate` (secuencial: recorre los flujos uno a uno reseteando la DB antes de cada uno; ni compila ni edita) y `fix` (serial: el fix-loop completo hasta que el flujo pasa). La usa el especialista `flow-validator`. Úsala cuando necesites probar un flujo de un BC end-to-end, validar escenarios de error/borde, o confirmar que un UC está realmente "completado" (no solo compilando).

Punto de entrada de la Fase 3 del pipeline DSL: orquesta la implementación completa de un bounded context generado por la Fase 2 lanzando agentes especialistas en un DAG (Fase 1 en paralelo: `todo-implementer` completa los `// TODO: implement business logic` e `infra-provisioner` levanta la infraestructura; Fase 2: un `flow-validator` en modo `validate` recorre secuencialmente todos los flujos —reseteando la DB antes de cada uno— y, si hay rojos, una única pasada `fix` secuencial que un solo agente aplica sobre todos los flujos rojos, validando todos los escenarios de cada flujo; Fase 3 en paralelo: `java-quality-auditor` audita la calidad Java y `postman-builder` emite las colecciones Postman). Es el único interlocutor con el usuario. Esta skill debe usarse cuando el usuario diga "implementa el BC X", "completa los TODO del bounded context Y", "fase 3 para el BC Z", "implementa la lógica de negocio de X", o pida finalizar la Fase 3 de un scaffold generado.

Referencia compartida de la Fase 3 del pipeline DSL, consultada por la skill de orquestación `logic-implementation` (el punto de entrada del usuario) y por los agentes especialistas. Define el DAG multi-agente, los roles, el contrato de handoff entre orquestador y especialistas, la adaptación por harness y —para TODOS los agentes— las reglas inviolables y los criterios de "cuándo detenerse". No es el punto de entrada del usuario: esta skill debe consultarse cuando se necesite coordinar el DAG de la Fase 3, conocer qué recibe y devuelve cada especialista, o aplicar las reglas compartidas al implementar o validar un bounded context.

Soporte para completar los // TODO de lógica de negocio (handlers, aggregates y domain services) de un bounded context generado por la Fase 2. Reúne las guías de detalle del especialista `todo-implementer`: cómo leer los artefactos de diseño (`{bc}.yaml` / `{bc}-flows.md`), cuándo y cómo extraer domain services, cuándo usar concurrencia con hilos virtuales y cómo integrar el almacenamiento de objetos. Úsala al implementar la lógica de negocio de un BC, completar handlers con `UnsupportedOperationException`, o decidir si un caso requiere domain service / hilos virtuales / storage.

Levanta y verifica la infraestructura local de un proyecto Spring Boot generado por la Fase 2 (base de datos, broker, cache, Keycloak, MinIO…) con Docker o Podman, y provee el cheatsheet de comandos CLI exactos por servicio para comprobar su estado. La usan el especialista `infra-provisioner` (Paso 0b) y el `flow-validator` (para verificar side effects). Úsala cuando necesites arrancar el compose, comprobar que un servicio está operativo, o consultar el comando CLI exacto de `psql`/`mysql`/`sqlcmd`/`sqlplus`, `kcat`, `redis-cli`, `mc`, o el health de Keycloak/RabbitMQ.

Genera las colecciones Postman de un bounded context ya validado: `postman/{bc}-collection.json` (una carpeta por flujo `FL-{BC}-{N}`, una request por escenario A/B/C…, más una carpeta CRUD con los endpoints triviales del OpenAPI) y `postman/auth-collection.json` (compartido entre BCs, una request de token por rol — solo se crea si no existe). La usa el especialista `postman-builder`. Úsala cuando necesites emitir/regenerar colecciones Postman reutilizables para revalidar los flujos de un BC manualmente.

Audita y ajusta la calidad del código Java de un bounded context ya implementado y validado: imports faltantes o sin usar, inyección de dependencias por constructor, campos `final`, tipado de excepciones de dominio, uso correcto de `@Transactional`, convenciones de `AGENTS.md` (sin Lombok ni setters en dominio). Aplica **solo cambios no-conductuales** que preserven el comportamiento ya validado por `flow-validator`, y define la frontera "no-conductual vs conductual". La usa el especialista `java-quality-auditor`. Úsala al pulir/limpiar el código Java de un BC sin cambiar su comportamiento.

Construir o actualizar el system.yaml de un proyecto eva4j. Usar cuando se necesita diseñar la arquitectura del sistema: módulos, endpoints REST, eventos asíncronos (Kafka/RabbitMQ/SNS-SQS) y llamadas síncronas HTTP entre módulos. Invoca este skill al describir un nuevo sistema, al agregar módulos, al rediseñar integraciones entre servicios, o cuando el usuario pida diagramas C4 de contexto o contenedores del sistema. USE FOR: system architecture design, adding modules, designing async event flows, sync HTTP calls between modules, generating C4 diagrams, building system.yaml + domain YAML + module specifications.

Transformar una idea vaga de producto en requisitos funcionales robustos y estructurados para diseño de sistemas. USE FOR: cuando el usuario tiene una idea de negocio, startup, feature o producto y necesita convertirla en especificación funcional clara antes de diseñar la arquitectura; cuando se dice 'quiero construir un sistema para...', 'tengo una idea de una app que...', 'necesito un sistema que gestione...', 'cómo empiezo a diseñar...'. PRODUCES: USER_FLOWS.md, VALIDATION_FLOWS.md y FUNCTIONAL_REQUIREMENTS.md listos para usar como entrada de build-system-yaml o build-temporal-system. Este skill SIEMPRE debe ejecutarse antes de build-system-yaml cuando el input es una descripción informal o una idea de negocio sin estructurar.

Build or update a Temporal-based system with eva4j. Use when designing a system architecture that uses Temporal as the orchestration engine for cross-module communication instead of Kafka/RabbitMQ. Invoke this skill when the user mentions Temporal workflows, sagas, durable orchestration, activity-based communication between modules, or wants to design a system where Temporal replaces both async messaging and sync HTTP calls between internal modules. USE FOR: Temporal system architecture design, designing cross-module workflows and sagas, defining activities per module, building system.yaml with orchestration section, generating domain YAMLs with activities/workflows/notifies, C4 diagrams for Temporal systems. DO NOT USE FOR: Kafka/RabbitMQ-based systems (use build-system-yaml instead), single-module projects without cross-module communication, Temporal worker implementation details.

Implementar casos de uso (use cases) en proyectos generados por eva4j siguiendo arquitectura hexagonal, DDD y código limpio. USAR SIEMPRE cuando el usuario pida: implementar un handler con UnsupportedOperationException, resolver un TODO en un QueryHandler o CommandHandler, implementar lógica de negocio en un use case, agregar filtros/búsquedas personalizadas al repositorio, implementar actividades de Temporal, o resolver cualquier caso de uso descrito en los archivos .md del directorio system/. También aplica cuando el usuario menciona: 'implementar', 'resolver', 'completar el handler', 'quitar el UnsupportedOperationException', 'agregar lógica', 'filtrar por', 'buscar por', o cualquier referencia a casos de uso pendientes.