compose

Compose Expert Skill

Non-opinionated, practical guidance for writing correct, performant Compose code — across Android, Desktop, iOS, and Web. Covers Jetpack Compose and Compose Multiplatform. Backed by analysis of actual source code from androidx/androidx and JetBrains/compose-multiplatform-core.

Workflow

When helping with Compose code, follow this checklist:

1. Understand the request

• What Compose layer is involved? (Runtime, UI, Foundation, Material3, Navigation)
• Is this a state problem, layout problem, performance problem, or architecture question?
• Is this Android-only or Compose Multiplatform (CMP)?

2. Analyze the design (if visual reference provided)

• If the user shares a Figma frame, screenshot, or design spec, consult references/design-to-compose.md
• Decompose the design into a composable tree
• Transcribe, don't adapt — copy, casing, punctuation and number format come across exactly; resolve each value to the token that matches it exactly, and add a token the theme lacks rather than substituting the nearest (references/design-to-compose.md)
• Map design tokens to MaterialTheme, spacing to CompositionLocals
• Identify animation needs — references/animation.md (contentKey, phase rule, M3 motion tokens), references/animation-recipes.md (shimmer/loading-crossfade + choreography), or references/animation-advanced.md (shared-element, predictive back, drawBehind-for-color)

3. Consult the right reference

Read the relevant reference file(s) from references/ before answering:

4. Apply and verify

• Write code that follows the patterns in the reference
• Flag any anti-patterns you see in the user's existing code
• Suggest the minimal correct solution — don't over-engineer

5. Cite the source

When referencing Compose internals, point to the exact source file:

// See: compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/Composer.kt

Key Principles

1. Compose thinks in three phases: Composition → Layout → Drawing. State reads in each

phase only trigger work for that phase and later ones.

1. Recomposition is frequent and cheap — but only if you help the compiler skip unchanged

scopes. Use stable types, avoid allocations in composable bodies.

1. Modifier order matters. Modifier.padding(16.dp).background(Color.Red) is visually

different from Modifier.background(Color.Red).padding(16.dp).

1. State should live as low as possible and be hoisted only as high as needed. Don't put

everything in a ViewModel just because you can.

1. Side effects exist to bridge Compose's declarative world with imperative APIs. Use the

right one for the job — misusing them causes bugs that are hard to trace.

1. Compose Multiplatform shares the runtime but not the platform. UI code in

commonMain is portable. Platform-specific APIs (LocalContext, BackHandler, Window) require expect/actual or conditional source sets.

Source Code Verification

Always verify against live source code — never rely on training data alone.

Tier 1 (Preferred): android-sources MCP server

When available, use the MCP tools for fast, precise lookups:

lookup_class(className: "LazyListState")
lookup_method(className: "Composer", methodName: "startRestartGroup")
search_in_source(query: "fun rememberLazyListState")
list_class_members(className: "Modifier")
get_class_hierarchy(className: "LazyListState")
find_references(className: "SnapshotState", methodName: "value")

Tier 2 (Fallback): Raw GitHub URLs

If the MCP server is unavailable, fetch source directly:

• AndroidX: https://raw.githubusercontent.com/androidx/androidx/androidx-main/{path}
• Directory listing: gh api repos/androidx/androidx/contents/{path}
• CMP: https://raw.githubusercontent.com/JetBrains/compose-multiplatform-core/jb-main/{path}
• AOSP platform: https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/{path}?format=TEXT (base64)

Two-layer approach

1. Start with guidance — read the topic-specific reference (e.g., references/state-management.md)
2. Verify against live source — use MCP tools or raw GitHub to confirm behavior

Source tree map

androidx/androidx (branch: androidx-main)
├── compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/
├── compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/
├── compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/
├── compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/
├── compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/
└── compose/navigation/navigation-compose/src/commonMain/kotlin/androidx/navigation/compose/

compose-multiplatform-core (branch: jb-main)
├── compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/window/
├── compose/ui/ui/src/iosMain/kotlin/androidx/compose/ui/window/
├── compose/ui/ui/src/webMain/kotlin/androidx/compose/ui/window/
├── compose/ui/ui/src/skikoMain/kotlin/androidx/compose/ui/
└── compose/foundation/foundation/src/skikoMain/kotlin/androidx/compose/foundation/

compose-multiplatform (resources library)
└── components/resources/library/src/commonMain/

Authoritative Docs

For guidance, best practices, or migration guides — things source code alone can't answer — prefer Google's Android Knowledge Base over web search:

android docs search "LazyColumn performance"              # ranked kb:// URLs + summaries
android docs fetch kb://android/develop/ui/compose/lists  # full content of a result

4800+ curated docs across Android, Wear, TV, KMP, and Glance. Use this when the internal files in references/ don't cover your question; use source code lookups (above) when you need implementation details rather than guidance.