메뉴
Use when designing, implementing, or reviewing platform-specific integrations in KMP projects, including source-set placement, hierarchical sharing, expect/actual usage, platform API access, and shared-to-native abstraction boundaries.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when reviewing implemented Kotlin Multiplatform / Compose Multiplatform code for architecture consistency, business-logic placement, state correctness, concurrency, Compose quality, design-system usage, security, performance, resilience, and maintainability.
Use when reviewing KMP architecture, feature proposals, PR structure, layer boundaries, state-holder design, Android entry-point discipline, source-set placement, modularization, and long-term maintainability in Kotlin Multiplatform / Compose Multiplatform projects.
Refactor discipline for existing codebases. Enforces scope control, migration safety, compatibility, observability, and tests to keep refactors reviewable and low-risk.
Use when diagnosing and fixing bugs in a Kotlin Multiplatform project. Focus on root-cause analysis, minimal safe fixes, KMP correctness, UI/state/data/persistence/concurrency issues, and regression prevention.
Use when implementing or extending a feature in a Kotlin Multiplatform project. Provides pre-coding inspection, KMP source-set discipline, state pipeline design, architectural defaults, security/performance guardrails, and implementation rules. Forward-looking only — not a review skill.
Use when reviewing or designing Gradle build structure for KMP projects — shared build logic, convention plugins, version catalogs, Android KMP plugin usage, source-set configuration, and module dependency hygiene.
| name | kotlin-platform-kmp-bridges |
| description | Use when designing, implementing, or reviewing platform-specific integrations in KMP projects, including source-set placement, hierarchical sharing, expect/actual usage, platform API access, and shared-to-native abstraction boundaries. |
| license | Apache-2.0 |
| metadata | {"author":"Mariano Miani","version":"1.2.0"} |
Use this skill when designing, implementing, or reviewing platform-specific integrations and shared-to-native boundaries in a Kotlin Multiplatform project.
This skill is intentionally strict. Its purpose is to keep platform-specific code at the edges, maximize valid sharing through source-set hierarchy, avoid unnecessary expect/actual, and preserve testable abstractions between shared and native code.
The bridge design should optimize for:
expect/actual usageDo not default to expect/actual for every native dependency.
Start from the least specialized mechanism that solves the problem cleanly.
Unless the project has a strong reason not to, prefer these defaults:
commonMain when it is valid for all declared targetsexpect/actual mainly for narrow platform-specific access pointsactual implementations in intermediate source sets like iosMain when one implementation is valid for several platform targetsCheck whether code is placed in the highest valid shared source set before splitting into platform code.
Prefer:
commonMain for logic valid for all targetsFlag as a concern when:
commonMain is underused because the design assumes platform differences before validating themKotlin explicitly supports sharing code among similar targets through hierarchical project structure and intermediate source sets. Examples include iosMain for several iOS targets. (https://kotlinlang.org/docs/multiplatform/multiplatform-share-on-platforms.html)(https://kotlinlang.org/docs/multiplatform/multiplatform-share-on-platforms.html)
Check whether:
Flag as a concern when:
iosX64Main, iosArm64Main, and iosSimulatorArm64Main duplicate the same bridge codeactual implementation but does notThe hierarchy docs recommend the default hierarchy template for most projects and warn that explicit dependsOn() edges cancel it unless you deliberately reapply or opt out. (https://kotlinlang.org/docs/multiplatform/multiplatform-hierarchy.html)(https://kotlinlang.org/docs/multiplatform/multiplatform-hierarchy.html)
Check whether:
Flag as a concern when:
dependsOn() graphs exist for cases already covered by the default templateBefore introducing custom bridge code, check whether an existing multiplatform library or platform library already solves the problem.
Kotlin explicitly recommends first checking for multiplatform libraries, and notes that Kotlin/Native ships platform libraries such as Foundation, UIKit, and POSIX that are available to native shared source sets. (https://kotlinlang.org/docs/multiplatform/multiplatform-connect-to-apis.html)
Check whether:
Flag as a concern when:
Kotlin’s platform-API guidance supports several approaches:
expect/actual functions/propertiesReview whether the chosen mechanism matches the problem size.
Prefer:
expect/actual functions or properties for small platform-specific access pointsFlag as a concern when:
expect/actual is used for complex object graphs that would be cleaner as interfacesIf expect/actual is used, review it strictly.
Kotlin requires:
expect declaration in common codeactual declarations for all relevant targetsexpect and actualexpect declaration. (https://kotlinlang.org/docs/multiplatform/multiplatform-expect-actual.html)(https://kotlinlang.org/docs/multiplatform/multiplatform-expect-actual.html)Check whether:
actualactual implementations are placed at the right hierarchy levelFlag as a concern when:
expect declarations include implementationactualactual code is duplicated in concrete targets when an intermediate source set would sufficeKotlin explicitly recommends relying on standard language constructs wherever possible. The expect/actual mechanism overall is stable, but expect/actual classes (non-annotation expect class declarations) carry restrictions: in Kotlin 2.0+, non-annotation expect classes must have a corresponding actual class (not a typealias) in each target, and their member declarations must match. This makes expect/actual classes heavier to maintain than expect functions or properties. Always check the current Kotlin docs for the latest stability status of this feature. (https://kotlinlang.org/docs/multiplatform/multiplatform-expect-actual.html)(https://kotlinlang.org/docs/multiplatform/multiplatform-expect-actual.html)
Check whether:
expect/actual classes are used only when truly justifiedFlag as a concern when:
expect classes without needShared code should define what the app needs, not how each platform implements it.
Check whether:
Flag as a concern when:
Kotlin documents passing platform implementations from platform entry points as a valid alternative to expect/actual. In practice, this means: at the platform main function or app startup (e.g. MainActivity.onCreate() on Android, the app entry point on iOS), the platform constructs concrete implementations of shared interfaces and passes them into shared code — typically via constructor injection, factory functions, or a DI container. Shared code receives an already-constructed dependency and does not need to know which platform provided it. (https://kotlinlang.org/docs/multiplatform/multiplatform-connect-to-apis.html)
What "entry-point wiring" means concretely: the platform's main entry point (e.g., Android Application.onCreate(), iOS main.kt, desktop main()) constructs platform-specific implementations and injects them into shared code — typically through a constructor, factory function, or DI graph — rather than having shared code create or locate them itself. Shared code depends on an interface or abstract type; only the entry point knows the concrete class.
Check whether:
Flag as a concern when:
Check whether platform-specific types stay behind the bridge.
Prefer:
Flag as a concern when:
The hierarchy docs note that intermediate source sets can access APIs available for the targets they compile to, and Kotlin/Native platform libraries can be used from such shared native source sets. (https://kotlinlang.org/docs/multiplatform/multiplatform-hierarchy.html)(https://kotlinlang.org/docs/multiplatform/multiplatform-hierarchy.html)
Check whether:
iosMain or another appropriate intermediate source set when one implementation covers the whole familyFlag as a concern when:
Check whether:
Flag as a concern when:
expect/actual choices make fakes harder than necessaryLikely to cause architectural drift or invalid source-set/platform coupling.
Examples:
commonMainactual implementationsexpect and actualWorkable, but likely to create maintenance cost.
Examples:
expect/actual where interfaces would be cleanerStructurally acceptable but worth improving.
Examples:
When performing the review, respond with:
Bridge summary
What is structurally sound
Issues by review dimension
Severity for each issue
Concrete recommendations
Suggested target structure
Open risks
Be direct and practical. Do not praise a bridge just because it works on one platform. If the bridge design is weak, say why clearly.
commonMain