kotlin-platform-kmp-bridges

Name: kotlin-platform-kmp-bridges
Author: mmiani

56stars5forks

How to install kotlin-platform-kmp-bridges?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-platform-kmp-bridges

$npx -y skills add mmiani/kotlin-kmp-claude-agent-skills --skill kotlin-platform-kmp-bridges

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Kotlin Multiplatform Platform Bridges
2
3	Use this skill when designing, implementing, or reviewing platform-specific integrations and shared-to-native boundaries in a Kotlin Multiplatform project.
4
5	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.
6
7	## Primary goals
8
9	The bridge design should optimize for:
10
11	- correct source-set placement
12	- maximum valid code sharing before introducing platform splits
13	- clear shared-to-native abstraction boundaries
14	- minimal and justified `expect`/`actual` usage
15	- platform API access through the least-coupled mechanism
16	- reuse across similar platforms through intermediate source sets
17	- testability and replaceability of native integrations
18	- avoidance of platform/vendor types leaking into shared business logic
19
20	Do not default to `expect`/`actual` for every native dependency.
21	Start from the least specialized mechanism that solves the problem cleanly.
22
23	---
24
25	## Official defaults to prefer
26
27	Unless the project has a strong reason not to, prefer these defaults:
28
29	- share code in `commonMain` when it is valid for all declared targets
30	- share code among similar platforms through hierarchical source sets before duplicating implementations
31	- use the default hierarchy template unless the project truly requires custom hierarchy wiring
32	- check for existing multiplatform libraries before writing platform bridges
33	- prefer regular interfaces and injected implementations when they model the dependency well
34	- use `expect`/`actual` mainly for narrow platform-specific access points
35	- keep `actual` implementations in intermediate source sets like `iosMain` when one implementation is valid for several platform targets
36	- keep platform-specific registration, lifecycle, packaging, and SDK wiring outside shared business logic
37
38	---
39
40	## Review dimensions
41
42	### 1. Sharing-first source-set placement
43
44	Check whether code is placed in the highest valid shared source set before splitting into platform code.
45
46	Prefer:
47	- `commonMain` for logic valid for all targets
48	- intermediate shared source sets for code valid for some but not all targets
49	- platform source sets only when APIs or behavior genuinely differ
50
51	Flag as a concern when:
52	- code is duplicated in platform source sets even though it could live in shared code
53	- platform splitting happens too early
54	- `commonMain` is underused because the design assumes platform differences before validating them
55
56	### 2. Intermediate source-set usage
57
58	Kotlin 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)
59
60	Check whether:
61	- similar targets reuse logic through intermediate source sets
62	- intermediate source sets are used for platform-family APIs and dependencies where appropriate
63	- platform-family bridges are not duplicated unnecessarily across concrete targets
64
65	Flag as a concern when:
66	- `iosX64Main`, `iosArm64Main`, and `iosSimulatorArm64Main` duplicate the same bridge code
67	- one platform family could share an `actual` implementation but does not
68	- intermediate source sets are ignored without reason
69
70	### 3. Default hierarchy template vs manual hierarchy
71
72	The 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)
73
74	Check whether:
75	- the project uses the default hierarchy template when it fits
76	- manual hierarchy configuration is justified
77	- additional source sets are introduced only when the default template is insufficient
78	- hierarchy changes preserve clarity rather than creating hidden build complexity
79
80	Flag as a concern when:
81	- manual `dependsOn()` graphs exist for cases already covered by the default template
82	- the hierarchy is custom but offers no clear architectural benefit
83	- source-set topology is difficult to reason about
84
85	### 4. Platform-library-before-bridge rule
86
87	Before introducing custom bridge code, check whether an existing multiplatform library or platform library already solves the problem.
88
89	Kotlin explicitly recommends first checking for multiplatform libraries, and

People who liked this also viewed

6 picks

Type

kotlin-platform-kmp-bridges

56stars5forks

View on GitHub

How to install kotlin-platform-kmp-bridges?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-platform-kmp-bridges

$npx -y skills add mmiani/kotlin-kmp-claude-agent-skills --skill kotlin-platform-kmp-bridges

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Kotlin Multiplatform Platform Bridges
2
3	Use this skill when designing, implementing, or reviewing platform-specific integrations and shared-to-native boundaries in a Kotlin Multiplatform project.
4
5	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.
6
7	## Primary goals
8
9	The bridge design should optimize for:
10
11	- correct source-set placement
12	- maximum valid code sharing before introducing platform splits
13	- clear shared-to-native abstraction boundaries
14	- minimal and justified `expect`/`actual` usage
15	- platform API access through the least-coupled mechanism
16	- reuse across similar platforms through intermediate source sets
17	- testability and replaceability of native integrations
18	- avoidance of platform/vendor types leaking into shared business logic
19
20	Do not default to `expect`/`actual` for every native dependency.
21	Start from the least specialized mechanism that solves the problem cleanly.
22
23	---
24
25	## Official defaults to prefer
26
27	Unless the project has a strong reason not to, prefer these defaults:
28
29	- share code in `commonMain` when it is valid for all declared targets
30	- share code among similar platforms through hierarchical source sets before duplicating implementations
31	- use the default hierarchy template unless the project truly requires custom hierarchy wiring
32	- check for existing multiplatform libraries before writing platform bridges
33	- prefer regular interfaces and injected implementations when they model the dependency well
34	- use `expect`/`actual` mainly for narrow platform-specific access points
35	- keep `actual` implementations in intermediate source sets like `iosMain` when one implementation is valid for several platform targets
36	- keep platform-specific registration, lifecycle, packaging, and SDK wiring outside shared business logic
37
38	---
39
40	## Review dimensions
41
42	### 1. Sharing-first source-set placement
43
44	Check whether code is placed in the highest valid shared source set before splitting into platform code.
45
46	Prefer:
47	- `commonMain` for logic valid for all targets
48	- intermediate shared source sets for code valid for some but not all targets
49	- platform source sets only when APIs or behavior genuinely differ
50
51	Flag as a concern when:
52	- code is duplicated in platform source sets even though it could live in shared code
53	- platform splitting happens too early
54	- `commonMain` is underused because the design assumes platform differences before validating them
55
56	### 2. Intermediate source-set usage
57
58	Kotlin 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)
59
60	Check whether:
61	- similar targets reuse logic through intermediate source sets
62	- intermediate source sets are used for platform-family APIs and dependencies where appropriate
63	- platform-family bridges are not duplicated unnecessarily across concrete targets
64
65	Flag as a concern when:
66	- `iosX64Main`, `iosArm64Main`, and `iosSimulatorArm64Main` duplicate the same bridge code
67	- one platform family could share an `actual` implementation but does not
68	- intermediate source sets are ignored without reason
69
70	### 3. Default hierarchy template vs manual hierarchy
71
72	The 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)
73
74	Check whether:
75	- the project uses the default hierarchy template when it fits
76	- manual hierarchy configuration is justified
77	- additional source sets are introduced only when the default template is insufficient
78	- hierarchy changes preserve clarity rather than creating hidden build complexity
79
80	Flag as a concern when:
81	- manual `dependsOn()` graphs exist for cases already covered by the default template
82	- the hierarchy is custom but offers no clear architectural benefit
83	- source-set topology is difficult to reason about
84
85	### 4. Platform-library-before-bridge rule
86
87	Before introducing custom bridge code, check whether an existing multiplatform library or platform library already solves the problem.
88
89	Kotlin explicitly recommends first checking for multiplatform libraries, and

People who liked this also viewed

6 picks

Type