What problem does it solve? Deciding where UI state should live in a Jetpack Compose codebase is a recurring source of confusion: state hoisted too high creates coupling, while state kept too local blocks sharing and testing. This Skill provides a decision framework for choosing between local remember state, hoisted composable parameters, plain state holder classes, and screen-level ViewModels. ## Core Features & Use Cases - Decision table: Maps concrete situations (single-composable state, sibling sharing, UI logic extraction, business logic) to the correct state owner. - Plain state holder pattern: Provides a complete Kotlin template with @Stable classes, remember...State factory functions, and intent-style methods for UI behaviors like search, scroll, and focus. - Common mistakes reference: Lists anti-patterns such as over-hoisting, putting repository calls in Compose state holders, and calling animation suspend functions from viewModelScope, each with its fix. - Use Case: When a search screen accumulates query text, filter sheet visibility, list scroll position, and focus handling in one composable, use this Skill to extract a cohesive ProductSearchState holder while keeping repository-backed suggestion logic in the ViewModel. ## Quick Start Ask the AI to review your composable and decide where each piece of UI state should live using the compose state hoisting guidelines.
