Habilidades domain-modeling
📦

domain-modeling

Seguro 📁 Acceso al sistema de archivos

Construye modelos de dominio precisos con vocabulario activo

Los proyectos de software sufren cuando los equipos usan terminología inconsistente o pierden el rastro de por qué se tomaron las decisiones. Esta habilidad te ayuda a construir y refinar activamente tu modelo de dominio cuestionando términos, inventando casos edge y capturando decisiones en CONTEXT.md y ADRs.

Soporta: Claude Codex Code(CC)
🥉 74 Bronce
1

Descargar el ZIP de la skill

2

Subir en Claude

Ve a Configuración → Capacidades → Skills → Subir skill

3

Activa y empieza a usar

Pruébalo

Usando "domain-modeling". El usuario dice: 'Cuando un cliente cancela su pedido, necesitamos reembolsar el pago.'

Resultado esperado:

Respuesta: "Tu glosario define 'cancelación' como terminar un pedido antes del cumplimiento, pero reembolso es un concepto de facturación. ¿Estás cancelando el pedido y disparando un evento de reembolso en Facturación, o la cancelación es en sí misma una operación de facturación? Definamos qué contexto es dueño de esto."

Usando "domain-modeling". El usuario decide usar PostgreSQL para el modelo de escritura en un sistema event-sourced.

Resultado esperado:

Respuesta: "Esto califica para un ADR: difícil de revertir (elección de base de datos), sorprendente sin contexto (¿por qué Postgres en lugar de un event store?), compromiso real (se consideraron alternativas). Creando ADR-0003-postgres-para-modelo-de-escritura.md ahora."

Auditoría de seguridad

Seguro
v1 • 6/23/2026

This skill contains only markdown documentation describing domain modeling practices, CONTEXT.md format, and ADR format. Static analysis flagged false positives: backtick matches are markdown inline code formatting, not shell execution; cryptographic matches are coincidental word fragments in documentation; system reconnaissance flags refer to file path references in examples, not actual filesystem access. No executable code, scripts, network calls, or malicious patterns were found.

3
Archivos escaneados
184
Líneas analizadas
1
hallazgos
1
Auditorías totales

Factores de riesgo

Auditado por: claude

Puntuación de calidad

38
Arquitectura
100
Mantenibilidad
87
Contenido
50
Comunidad
100
Seguridad
91
Cumplimiento de la especificación

Lo que puedes crear

Iniciar un nuevo modelo de dominio

Úsalo al comenzar un nuevo proyecto para establecer el vocabulario inicial y documentar las decisiones arquitectónicas clave antes de escribir código.

Resolver conflictos de terminología

Úsalo durante discusiones de equipo cuando diferentes miembros usan distintas palabras para el mismo concepto y se necesita claridad.

Documentar decisiones arquitectónicas

Úsalo al tomar decisiones tecnológicas significativas que futuros desarrolladores necesitarán entender, como la selección de base de datos o patrones de integración.

Prueba estos prompts

Iniciar el modelado de dominio
Ayúdame a construir el modelo de dominio para este proyecto. Empieza leyendo CONTEXT.md (si existe) y luego cuestiona activamente cualquier terminología que use mientras discutimos el diseño.
Resolver ambigüedad de terminología
Acabo de usar el término "account" en nuestra discusión. Revisa CONTEXT.md y dime si esto entra en conflicto con nuestro vocabulario definido, luego propón el término preciso que deberíamos usar.
Poner a prueba los límites del dominio
Acabamos de definir la relación entre Order e Invoice. Inventa 3 escenarios de casos edge que exploren el límite entre estos dos conceptos y nos obliguen a ser precisos.
Registrar una decisión arquitectónica
Acabamos de decidir usar event sourcing para el modelo de escritura. Comprueba si esto cumple los tres criterios de ADR (difícil de revertir, sorprendente sin contexto, compromiso real). Si es así, crea el ADR usando el formato de ADR-FORMAT.md.

Mejores prácticas

  • Crea CONTEXT.md y ADRs de forma perezosa, solo cuando tengas algo significativo que registrar
  • Cuestiona cada término ambiguo de inmediato en lugar de dejar que la confusión se acumule
  • Mantén las definiciones de CONTEXT.md en una o dos frases enfocadas en lo que el término ES
  • Escribe ADRs solo para decisiones que sean difíciles de revertir, sorprendentes sin contexto o que involucren compromisos reales

Evitar

  • Tratar CONTEXT.md como una especificación o bloc de notas para detalles de implementación
  • Escribir ADRs para decisiones obvias que no tienen alternativas reales
  • Añadir conceptos generales de programación (timeouts, tipos de error) al glosario
  • Agrupar las actualizaciones de terminología en lotes en lugar de capturarlas inline a medida que se resuelven

Preguntas frecuentes

¿Cuál es la diferencia entre CONTEXT.md y un ADR?
CONTEXT.md es un glosario de términos del dominio y sus definiciones precisas. Un ADR registra una decisión arquitectónica específica, por qué se tomó y qué alternativas se consideraron.
¿Cuándo debería crear un ADR?
Solo cuando se cumplen los tres criterios: la decisión es difícil de revertir, sorprendería a un lector futuro sin contexto, y había alternativas genuinas con un compromiso real.
¿Funciona esta habilidad con repositorios multi-contexto?
Sí. Si existe un CONTEXT-MAP.md en la raíz, la habilidad lo lee para encontrar todos los contextos y sus ubicaciones, luego infiere a qué contexto se refiere una discusión.
¿Puede esta habilidad generar código?
No. Esta habilidad produce solo archivos de documentación markdown (CONTEXT.md, ADRs). No genera ni modifica código fuente.
¿Cómo maneja la habilidad la terminología en conflicto?
Cuando usas un término que entra en conflicto con el glosario existente, la habilidad lo señala de inmediato y pregunta qué definición es la correcta antes de continuar.
¿Qué estructura de archivos espera esta habilidad?
Los repositorios de contexto único tienen CONTEXT.md en la raíz. Los repositorios multi-contexto tienen un CONTEXT-MAP.md en la raíz que apunta a archivos específicos de cada contexto. Los ADRs viven en docs/adr/ con numeración secuencial.

Detalles del desarrollador

Estructura de archivos