What problem does it solve? Kotlin Multiplatform projects often leak platform types like Context or UIViewController into commonMain, or accumulate domain logic inside actual implementations, making shared code untestable and hard to extend. This Skill provides decision rules for choosing the right boundary shape between shared and platform code. ## Core Features & Use Cases - Boundary Shape Selection: Decide between 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: Split platform services (clipboard, share, haptics, biometrics, notifications) into small fakeable interfaces instead of one monolithic Platform object. - Source-Set & AGP 9 Guidance: Covers skikoMain/appleMain intermediate source sets and AGP 9 KMP library constraints such as missing BuildConfig, no build variants, and no NDK. - Use Case: When adding a share feature to a KMP app, use this Skill to define a semantic ShareSheet interface in commonMain, bind an Activity-owned AndroidShareSheet in androidMain, and fake it in common JVM tests. ## Quick Start Ask the AI to design the KMP boundary for a platform capability such as clipboard access or a native map view in your Compose Multiplatform project.
