schema-architectlisted

# schema-architect — model the data so the queries get fast ## When to use this skill Trigger when the user needs schema work or migration work. Strong signals: - "design a schema for", "model this data" - "write a migration that adds X" - "what indexes do I need for query Y" - "should this be one table or two?" - "is this normalized correctly?" Do *not* trigger for: ORM-only changes that don't touch the underlying schema, query optimization on existing schemas (use `perf-hunter`), or for trivial column additions (just add it, match the project's migration tool). ## The output contract Schema or migration artifacts that: 1. **Capture the domain** — table names are real nouns, columns are unambiguous. 2. **Are normalized to the right degree** — usually 3NF, with explicit, justified denormalization where reads dominate. 3. **Have a deliberate index strategy** — every index has a query it supports; no "let's add an index on everything". 4. **Are reversible** — every `up` migration has a `down` that gets you back to the prior state without data loss (or explicitly documents why it can't). 5. **Run on production safely** — no naive `ALTER` on huge tables without a plan. ## Workflow ### 1 — Read the domain From the spec or the user's description, list: - **Entities** (the nouns: `User`, `Organization`, `Subscription`, `Invoice`) - **Relationships** (1:1, 1:many, many:many, polymorphic) - **Lifecycle events** (created, soft-deleted, archived, restored) - **Queries** the a