component-designlisted

# Component Design Guidance for structuring Unity MonoBehaviours: when to split responsibilities, how to wire communication between components, and how to enforce predictable lifecycle ordering. ## When to Apply Activate when the conversation involves: - Deciding whether to split one MonoBehaviour into multiple components - Choosing how components should communicate (events, interfaces, direct references) - Establishing component lifecycle order or initialization sequencing - Reviewing a MonoBehaviour that has grown large or hard to maintain - Naming or organizing components on a prefab - Setting up inter-system communication on a multi-component prefab Do NOT activate for questions about scene structure, data modeling, or prefab hierarchy — those go to `hades:unity-architect`, `hades:data-modeling`, or `hades:prefab-architecture`. ## Project Context Check Before making recommendations: 1. **Check existing patterns in the graph:** - Call `graph_query(edgeKind: "references", edgeTargetNamePattern: "MonoBehaviour", edgeTargetKind: "Class")` to understand component density and naming conventions already in the project - Call `search_by_name("*Manager*")` to detect existing manager patterns and whether the project uses service-locator style aggregators - Call `graph_query(edgeKind: "references", edgeTargetPath: "<path/to/Component.cs>")` on the focal component to find how it is already used across prefabs 2. **Check team decisions in memory:** - Call `recall_m