data-modelinglisted

# Data Modeling Guidance for structuring game data in Unity: choosing the right ScriptableObject pattern, separating config from runtime state, and designing a save system that survives versioning. ## When to Apply Activate when the conversation involves: - Deciding whether to use a ScriptableObject, a plain C# class, or MonoBehaviour fields to hold data - Designing item stats, enemy configs, ability definitions, or other designer-facing data - Building or extending a save/load system - Choosing how to serialize data (JSON, binary, PlayerPrefs, SQLite) - Managing a runtime registry of active entities (current enemies, items in world, etc.) - Inspector annotation and editor-time data authoring conventions Do NOT activate for pure component-structure questions (single MB vs. split) — those go to `hades:component-design`. Do NOT activate for prefab organization questions — those go to `hades:prefab-architecture`. ## Project Context Check Before making recommendations: 1. **Check existing assets and types in the graph:** - Call `search_by_name("*.asset")` to discover existing ScriptableObject assets and understand naming conventions - Call `graph_query(edgeKind: "references", edgeTargetNamePattern: "ScriptableObject", edgeTargetKind: "Class")` to find SO-derived types already defined in the project - Call `get_project_summary()` to understand project scale — asset count and assembly structure inform whether a lightweight pattern or a formal save-system layer is ap