Entity Model

Instructions

Create or update the entity model at docs/entity_model.md based on docs/requirements.md. The document contains an ER diagram and attribute tables.

DO NOT

• Add attributes/columns to the Mermaid diagram
• Write prose descriptions like "Key attributes: name, email..."
• Create a "Relationships" table

Document Structure

# Entity Model

## Entity Relationship Diagram

```mermaid
erDiagram
    ROOM_TYPE ||--o{ ROOM : "categorizes"
    GUEST ||--o{ RESERVATION : "makes"

ENTITY_NAME

One sentence describing the entity.

Required Format for Each Entity

Every entity MUST have:

1. A ### heading with the entity name in UPPERCASE (UPPER_SNAKE_CASE, e.g. ### ROOM_TYPE — never ### Room Type or ## Entity: Room Type)
2. One sentence description
3. An attribute table with exactly these 5 columns in this order: Attribute, Description, Data Type, Length/Precision, Validation Rules

Example Entity

ROOM_TYPE

Defines categories of rooms with shared characteristics.

Mermaid Diagram Rules

• Show entity names and relationships ONLY
• NO attributes inside entity blocks
• Use relationship syntax: ENTITY_A ||--o{ ENTITY_B : "relationship"

Data Types (use only these)

The Data Type column must use exactly these values — never SQL or ORM types such as VARCHAR, TEXT, CHAR, bigint, numeric, serial, smallint, UUID, Timestamp, or Enum:

The Length/Precision column holds the bare value (e.g. 10,2) — never a type expression like DECIMAL(10,2).

Validation Rules (use only these values)

Compose every Validation Rules cell from this vocabulary, using the exact wording — never a prose description, and never an empty cell, dash, or "N/A":

Examples: an email attribute is Not Null, Format: Email — never "must be a valid email address". A status attribute with a fixed set of states is Not Null, Values: Pending, Active, Completed, Cancelled — never "must be one of Pending, Active, Completed, Cancelled".

This table is a closed set: every Validation Rules cell is exactly one row from it. Do not combine rows into new patterns (Not Null, Unique, Format: Email is invalid — pick the one rule that matters most, here Not Null, Format: Email), and never write Min: without its matching Max: (Not Null, Min: 0 alone is invalid — use Not Null, Min: 0, Max: <upper bound> or just Not Null).

The same tables are available in references/REFERENCE.md. The path is relative to the folder containing this SKILL.md, not to the project root.

Multi-Column Constraints

If validation spans multiple columns, add a #### Constraints heading below the entity's attribute table and list each constraint as a bullet, one rule per bullet:

#### Constraints

- Check-out date must be after check-in date.
- The number of guests must not exceed the room type's capacity.

Never write the constraints as a bold **Constraints:** line or as an extra table row, and omit the heading when the entity has no multi-column constraint.

Workflow

1. Read the requirements document
2. Clarify before writing. Scan the sources with references/clarify-checklist.md and ask the user the questions whose answer changes the model and has no reasonable default — at most five, the most important first (entities and cardinality before ranges and lengths), each with a recommended option. Write the answers into the relationship lines, Validation Rules cells, and constraints they affect, never into a questions section. Decide everything else with the best default and report it as an assumption (step 7). When no one can answer — a pipeline run, a host without a way to ask, or the user said not to ask — take the recommended option for every question and report it as an assumption as well. Never ask about SQL types, indexes, or other implementation choices.
3. Use TodoWrite to create a task for each entity
4. Write the document header and ER diagram (relationships only)
5. For each entity:
   • Write ### heading
   • Write one sentence description
   • Write attribute table with 5 columns
   • Add a #### Constraints heading with a bullet list if needed
   • Mark todo complete
6. Validate the document:
   • Every entity in the ER diagram has a corresponding attribute table section
   • Every attribute table has exactly 5 columns
   • No attributes appear inside the Mermaid diagram entity blocks
   • All foreign keys reference existing entities
   • Every foreign key has a relationship line in the ER diagram
   • Every entity heading is ### with the name in UPPERCASE
   • Multi-column constraints are a #### Constraints bullet list below the table
   • All Data Type values come from the Data Types table above (no SQL types anywhere)
   • All validation rules use values from the Validation Rules table above
7. Report the Clarified, Assumed, and Open items as described in the clarification checklist