What this prompt does
This prompt scaffolds a modern Android app in Jetpack Compose using current design patterns. It moves through six steps: setting up a layered architecture, implementing state management, building type-safe navigation, creating a Material 3 design system, applying accessibility practices, and optimizing recomposition performance. The result is a coherent foundation where screens stay stateless and predictable as the app grows, which is what keeps a multi-module project from drifting into spaghetti.
The variables tailor the scaffold to your project. [architecture_pattern] and [dependency_injection] set the structural backbone, [module_count] defines the multi-module layout, and [state_approach] decides how UI state flows. [screen_count] and [nav_graph_count] shape the navigation graph, [brand_name] and [font_family] drive theming, [touch_target_size] enforces accessibility minimums, and [profiling_tool], [image_library], and [frame_budget] govern the performance pass. Each variable maps to a concrete decision you would otherwise make ad hoc on day one.
When to use it
- You are starting a native Android app and want a Compose architecture decided up front.
- You need a stateless-screen, hoisted-state pattern instead of logic scattered in composables.
- You want type-safe navigation across
[screen_count]screens and nested graphs. - You are building a Material 3 theme with light, dark, and dynamic color support.
- You want accessibility handled deliberately rather than retrofitted before launch.
- You need a concrete plan for hunting unnecessary recompositions and hitting a frame budget.
Example output
Expect a module structure for a multi-module project, a BaseViewModel exposing UI state via StateFlow and one-time events via SharedFlow, and a sealed UiState with Loading/Success/Error variants. From there you get a type-safe navigation graph with bottom navigation and deep linking, a Material 3 theme definition with light/dark color schemes and a typography scale, reusable composable components, accessibility annotations, and a recomposition-optimization checklist. It is a mix of architecture description and Kotlin code spread across the presentation, domain, and data layers, with the state-hoisting pattern applied so that screens receive state plus event callbacks rather than owning logic themselves.
Pro tips
- Match
[architecture_pattern]and[state_approach]to your team's experience; MVI withStateFlowis powerful but adds ceremony for small apps, so weigh the overhead against the size of the project. - Set
[module_count]to reflect real feature boundaries, not an arbitrary number, so the module graph stays meaningful. - Make sure
[screen_count]and[nav_graph_count]are consistent with the flows you actually have, including auth and onboarding back-stack handling. - Keep
[touch_target_size]at the platform minimum or above; accessibility scanners flag anything smaller. - Use
[profiling_tool]early and feed real findings back into the prompt; recomposition wins come from removing wasted work, not adding code. - Pick an
[image_library]you already use so lazy loading integrates cleanly with your existing build and caching setup.
