What problem does it solve? Kotlin Multiplatform projects struggle with deciding how shared code should reach platform APIs — choosing between expect/actual, common interfaces with DI, or separate platform screens — and often end up with monolithic Platform objects, leaky abstractions, and untestable actuals. ## Core Features & Use Cases - Boundary Shape Selection: Decision tables for choosing expect/actual functions, common interfaces with platform bindings, expect leaf composables, or fully separate platform screens based on testability, DI, and lifecycle needs. - Capability Granularity Rules: Guidance for splitting platform services (clipboard, share, haptics, biometrics, notifications) into small fakeable interfaces instead of one giant Platform object, with Activity-ownership rules for Android UI actions. - Source-Set Hierarchy & AGP 9 Constraints: Covers skikoMain/appleMain intermediate source sets, the new com.android.kotlin.multiplatform.library plugin limits (no BuildConfig, no variants, no NDK), and Compose Multiplatform interop patterns. - Use Case: When common code needs to trigger the system share sheet, this Skill guides you to define a semantic ShareSheet interface in commonMain, bind an Activity-scoped AndroidShareSheet via Hilt, and keep business rules in a common ShareUseCase testable with a fake. ## Quick Start Ask the AI to design a Kotlin Multiplatform boundary for accessing the device clipboard and haptics from shared commonMain code.