Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →athevon/compose-multiplatform
Compose Multiplatform / KMP patterns - expect/actual composables, platform-specific code, density and font handling cross-target, iOS/Android/Desktop interop.
Passed 21 of 24 test cases with the skill, and 18 of 24 without it.
3 fixed18 passed either way3 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
I am writing a responsive dashboard layout in `commonMain` for Android, iOS, and Web targets. I tried accessing `LocalConfiguration.current.screenWidthDp` to branch on window width, but the build fails on non-Android targets. What Compose API should I use instead to read the window container dimensions across all targets in `commonMain`?
| Checked | Without skill | With skill |
|---|---|---|
| The solution recommends using LocalWindowInfo to obtain window dimensions. | Missed | Passed |
The instructions your model reads when the skill loads.
Version-sensitive. Every API name, SDK gate and browser-support claim below was verified on 2026-09-08 against primary sources. What against, and when, is in
_jutsu/VERSIONS.md. If that date is old, re-verify before acting on a version number.
Compose Multiplatform (CMP) and Kotlin Multiplatform (KMP) patterns for cross-platform UI. Loaded for projects with
org.jetbrains.composeplugin. Foundation:../compose-motion/SKILL.mdfor animation API; this file covers what's specific to writing one Compose codebase for Android + iOS + Desktop + Web.
KMP (Kotlin Multiplatform) is the language and build infrastructure: shared Kotlin code compiled to JVM, Native (iOS, macOS, Linux, Windows), and Wasm. CMP (Compose Multiplatform) is the UI framework on top of KMP, built by JetBrains as a port of Jetpack Compose. You write a single Compose codebase in commonMain that runs on Android, iOS, Desktop (JVM), and Web (Wasm). Platform-specific code lives in androidMain, iosMain, desktopMain, wasmJsMain and is wired in via expect/actual declarations.
composeApp/
├── src/
│ ├── commonMain/ ← shared Compose code (most of the app)
│ │ └── kotlin/
│ ├── androidMain/ ← Android-specific (uses Activity, Context)
│ ├── iosMain/ ← iOS-specific (uses UIKit/UIView interop)
│ ├── desktopMain/ ← JVM desktop (uses java.awt/swing if needed)
│ └── wasmJsMain/ ← Wasm web target
├── build.gradle.kts
iosApp/ ← Xcode project consuming the generated framework
androidApp/ ← Android Application module (often merged into composeApp)
The commonMain folder should hold 80-95% of your code in a well-architected CMP project. If iosMain or androidMain start growing past a few hundred lines, you're probably leaking platform concerns into UI logic that could stay shared.
expect/actual patterntest cases passed, vs 18 / 24 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.