Android compose architecture review

Skill Desquared/agents-rules-skills/skills/android-compose-architecture-review

Analyze Jetpack Compose UI hierarchies and suggest MVVM/MVI or other architectural improvements. Use when reviewing existing Compose code, creating new Compose components, analyzing composable structure, or when the user asks about Compose architecture patterns. Best for code review and refactoring guidance.From its SKILL.md

Install

npx -y skills add Desquared/agents-rules-skills --skill android-compose-architecture-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.5 KB, as published. Nobody here has run it

Compose Architecture Review

When to Use This Skill:

Reviewing EXISTING Compose screens/ViewModels

Code review for architectural violations

Refactoring guidance for specific files

Validating state management patterns

When to Use project-architecture-analyst-android Agent Instead:

Planning NEW features (uncertain file placement)

Understanding project-wide architecture

Major changes affecting multiple modules

Need to discover existing patterns before implementing

Review Checklist

Separation of Concerns

Composables: presentation only (no business logic, network, DB)
ViewModels: state + business logic (StateFlow, events)
Repository/UseCase: data access separated from UI

State Management

remember - composable-local state only
rememberSaveable - survive config changes
ViewModel with StateFlow/MutableStateFlow - screen state
collectAsStateWithLifecycle() - lifecycle-aware collection
derivedStateOf - computed state from other state
CompositionLocal - shared read-only state
Use unidirectional data flow: state flows down, events flow up
Prefer stateless composables (receive value + onChange callbacks)
Use plain state-holder classes for complex state not tied to lifecycle
Prefer side effects via LaunchedEffect (async work), DisposableEffect (cleanup), SideEffect (framework integration), produceState, rememberCoroutineScope, or snapshotFlow rather than arbitrary side effects in composable bodies
Use SavedStateHandle for persistent state across process death

State Lifecycle Issues

No leaked ViewModels (use viewModel() or hiltViewModel())
Proper cleanup in ViewModel.onCleared()
StateFlow collected with lifecycle awareness
No unnecessary state hoisting

Dependency Injection

Dependencies injected (check project: Koin, Hilt, Dagger, or manual)
No hardcoded singletons in composables
ViewModels receive dependencies via constructor

Composable Design

Composables are small (single responsibility)
Complex screens broken into components
Reusable components extracted
Stateless composables preferred (state hoisting)

Common Issues

Issue	Fix
Business logic in composable	Extract to ViewModel
Network call in composable	Move to ViewModel with LaunchedEffect
Singleton in composable	Inject via DI or CompositionLocal
200+ line composable	Break into smaller components
State not hoisted	Hoist to parent or ViewModel
Side effects or network calls directly in composable	Wrap in `LaunchedEffect(key) { ... }` or move to ViewModel
Stateful composable when stateless would suffice	Hoist state and pass value + lambda

State Hoisting Pattern

Composable receives: value: T, onValueChange: (T) -> Unit
ViewModel holds: MutableStateFlow<T>

Severity

🔴 Critical: Architecture violation
🟡 Improvement: Better pattern available
🟢 Enhancement: Optional optimization

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.