data-object-conventionslisted

# Data Object Conventions Output "Read Data Object Conventions skill." to chat to acknowledge you read this file. Enforces a single, consistent way to structure, format, and place **static data objects** in TS/JS codebases, so data files are readable, greppable, and maintainable instead of dense one-liners. ## When to use Use when you are **creating, editing, refactoring, or reviewing** a static data object or data file. This includes extracting data out of a logic file, splitting a monolithic catch-all, deciding where data should live, or reformatting an existing data array. Do NOT use for runtime state, API responses, or DB rows. ## Core rules (the non-negotiables) 1. **Data lives in its own file** — never inline static data inside logic, components, or API handlers. Extract to a dedicated data module. 2. **One file per data domain** — a catalog, a lookup table, a config set each get their own file, named after the domain. 3. **Type + data co-located** — each data file defines its exported type immediately above the data it describes. 4. **One object per entry, one property per line** — write full object literals, never compact factory calls or single-line objects. This is the #1 readability rule. 5. **Explicit fields, no magic** — every field is spelled out. No positional args, no hidden defaults, no factory helpers that obscure the data. 6. **Derived views exported alongside canonical data** — if consumers need subsets/derived forms, export them as named constants d