Data model

Skill LuchoC-Dev/agent-kits/skills/data-model

Traduce el domain-model conceptual a un schema técnico — tablas/colecciones, tipos, claves, relaciones, índices y estrategia de migraciones. Elige el motor de persistencia. Trigger cuando el usuario quiera "diseñar la base de datos", "schema", "modelo de datos", "tablas", "SQL o NoSQL", "índices" o necesite cerrar la persistencia antes de implementar.From its SKILL.md

Install

npx -y skills add LuchoC-Dev/agent-kits --skill data-model

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.2 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it

Data Model

Rol

Sos un data architect. Tu trabajo es traducir el modelo conceptual del dominio a un schema técnico implementable, eligiendo el motor de persistencia adecuado.

Parámetro de depth

light — tablas/colecciones principales con sus campos clave y relaciones. Sin índices ni migraciones. Para Basic mode.
full — schema completo: tipos, claves, relaciones, índices, restricciones, estrategia de migraciones.

Precondición

Stack resuelto. Si existe domain-model (del pack context), es la base — cada entidad de dominio se traduce a una estructura de datos. No redefinas el dominio acá; traducilo.

Workflow

Paso 1 — Elegir el motor de persistencia

Decidí con criterio:

SQL relacional (Postgres, MySQL) — relaciones fuertes, transacciones, integridad. Default para la mayoría.
NoSQL documental (MongoDB) — datos jerárquicos, schema flexible, lectura por agregado.
Clave-valor / cache (Redis) — como complemento, no como fuente de verdad.
Combinaciones (poliglota) solo si hay una razón fuerte.

Justificá con la forma de los datos del domain-model y los patrones de acceso.

Paso 2 — Traducir entidades a estructuras

Por cada entidad de dominio: tabla/colección, campos con tipos técnicos, clave primaria. Marcá qué atributos del dominio se persisten y cuáles se derivan.

Paso 3 — Relaciones y claves

Traducí las relaciones del dominio: claves foráneas, tablas intermedias (N:N), o embedding (NoSQL). Decidí estrategia de borrado (cascada, restrict, soft-delete).

Paso 4 — Índices

Índices derivados de los patrones de acceso del api-contract (cada listado/filtro frecuente suele necesitar uno). No sobre-indexar.

Paso 5 — Migraciones

Estrategia de migraciones (herramienta, versionado del schema, datos seed). Política de cambios sin downtime si aplica.

Paso 6 — Link al domain-model

Si usaste domain-model como base, dejá un link bidireccional: en este archivo apuntá a domain-model, y notá en qué difiere el schema técnico del modelo conceptual (y por qué).

Output

Depth `full` — `docs/backend-design/NN-data-model.md`

NN = prefijo numérico de dos dígitos que asigna el workflow según el orden real de ejecución. No lo inventes — tomalo de la tabla del workflow que te invoca.

---
pack: backend-design
artifact: data-model
---

# Data Model

> Basado en el artefacto `domain-model`. Buscalo por su frontmatter (`artifact: domain-model`), no por el nombre de archivo.

## Motor de persistencia
**<Postgres | MongoDB | ...>** — <justificación>

## Estructuras
### <Tabla / Colección>
| Campo | Tipo | Restricciones | Notas |
|---|---|---|---|
| id | uuid | PK | ... |

## Relaciones
- <A> 1:N <B> vía `<fk>`, borrado <cascada | restrict | soft>.

## Índices
| Estructura | Campos | Por qué (patrón de acceso) |
|---|---|---|
| ... | ... | ... |

## Migraciones
> Herramienta, versionado, seed.

## Diferencias con el domain-model
> Dónde el schema técnico se aparta del modelo conceptual y por qué.

Depth `light`

Sección de docs/backend-design/backend-design.md:

## Data Model
**Motor:** <BD>
**Estructuras principales:**
| Tabla/Colección | Campos clave | Relaciones |
|---|---|---|
| ... | ... | ... |

Reglas duras

El domain-model es la base si existe — traducir, no redefinir.
No sobre-indexar — cada índice se justifica con un patrón de acceso real.
Decidir la estrategia de borrado explícitamente para cada relación.
No saltar a ORM-specific — el schema es conceptual-técnico; el ORM concreto se eligió en el stack.

Gives 0 of the 12 instructions most data backend skills give in ~1.0k tokens

Counted across 229 of the 229 authors here whose files we hold, read 2026-08-07

Separate business logic into service layersin 22 of 229, across 15 files
Retry failures with exponential backoffin 21 of 229, across 14 files
Select only needed database columnsin 20 of 229, across 13 files
Abstract data access into repository classesin 19 of 229, across 12 files
Use centralized error handlersin 17 of 229, across 10 files
Use AsNoTracking for read-only queriesin 16 of 229, across 4 files
Use async/await for all I/O operationsin 16 of 229, across 5 files
Implement structured loggingin 15 of 229, across 4 files
Use dependency injection for all servicesin 14 of 229, across 2 files
Use resource-based URLs for REST APIsin 13 of 229, across 7 files
Invalidate cache after data changesin 13 of 229, across 9 files
Use a dependency injection containerin 12 of 229, across 4 files

Said here and by no other author read

Use the domain-model as the base
Translate entities to data structures
Choose the persistence engine
Define explicit deletion strategies
Derive indexes from access patterns
Do not over-index

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.