What problem does it solve? Compose screens that take a ViewModel or component directly, collect flows, and render layout in one function become hard to preview, test, and reuse across Android, Desktop, TV, and KMP/CMP targets. This Skill guides the split between a state-holder composable and a plain UI composable. ## Core Features & Use Cases - State-holder/UI split pattern: Keep ViewModel access, flow collection, navigation, and side effects in a small state-holder composable while the UI composable takes immutable state and callbacks. - Decision tables: Rules of thumb for what belongs in each layer, including which UI-local state (scroll, focus, animation, text input) stays in the UI composable. - Common mistakes and boundaries: Fixes for leaking components into children, navigation inside UI, and guidance on when not to apply the pattern. - Use Case: A ProfileScreen takes a ProfileComponent, collects state with collectAsStateWithLifecycle, handles snackbar effects, then delegates layout to a plain ProfileScreen(state, callbacks) overload that is previewable and testable without DI. ## Quick Start Refactor my Compose screen so the ViewModel wiring and effect collection live in a state-holder composable and the layout lives in a plain UI composable taking state and callbacks.
