Entity-Relationship Diagram Skill

Before you write a migration, it pays to see the data model: the entities, their key fields, and how they relate (one-to-many, many-to-many). This skill turns a described domain into a clean Mermaid ER diagram with proper cardinality notation and the attributes that matter.

Required Inputs

Ask for these only if they aren't already provided:

• The entities — the core objects/tables (User, Order, Product…).
• Relationships — how they relate, and the cardinality (a user has many orders, an order has many line items).
• Key attributes — the important fields per entity (especially keys); full column lists aren't required.
• The domain — what the system does, so the model is realistic.

Output Format

[Domain] — data model

One line on the scope of the model.

erDiagram
    USER ||--o{ ORDER : places
    ORDER ||--|{ LINE_ITEM : contains
    PRODUCT ||--o{ LINE_ITEM : "appears in"
    USER {
        uuid id PK
        string email
        string name
    }
    ORDER {
        uuid id PK
        uuid user_id FK
        datetime created_at
        string status
    }
    LINE_ITEM {
        uuid id PK
        uuid order_id FK
        uuid product_id FK
        int qty
    }
    PRODUCT {
        uuid id PK
        string name
        decimal price
    }

Cardinality key — ||--o{ = one-to-many, }o--o{ = many-to-many, ||--|| = one-to-one.

Design notes — normalization choices, where a join table is needed, indexes worth adding, anything deferred.

Mermaid Rules (so it renders)

• Start with erDiagram. Relationship line: A ||--o{ B : label.
• Crow's-foot cardinality: || (exactly one), o{ (zero-or-many), |{ (one-or-many), o| (zero-or-one).
• Attribute blocks: ENTITY { type name PK } — mark keys with PK / .