Kmp performance observability
Skill Xopoko/plug-n-skills/plugins/kotlin-multiplatform/skills/kmp-performance-observability
Ready-to-install skills and plugins for Codex, Claude Code, and AI coding agents: practical workflows for app delivery, architecture, research, design, and agent tooling.
npx -y skills add Xopoko/plug-n-skills --skill kmp-performance-observabilityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Diagnose Kotlin Multiplatform performance and observability across Gradle build time, Kotlin/Native memory and GC, Compose Multiplatform jank, binary size, startup, runtime logging, and release-mode verification.
SKILL.md
2.4 KB, as published. Nobody here has run it
KMP Performance And Observability
Use this skill for KMP performance work: Compose jank, slow startup, Kotlin/Native memory pressure, binary size, Gradle build time, slow iOS framework builds, runtime observability, and release-mode measurement.
Loop
- Measure the symptom in a representative mode.
- Diagnose the named cause.
- Make the smallest targeted change.
- Verify with the same measurement surface.
Do not start by changing dependencies, compiler flags, or architecture.
Surfaces
- Gradle: build scans, task timings, configuration cache, build cache, worker count, Kotlin/Native incremental compilation.
- Kotlin/Native: GC logs, memory manager settings,
GC.lastGCInfo(), binary options, framework export shape,transitiveExport. - Compose: release-mode Android measurement, compiler metrics/reports, stability, recomposition tracing, lazy layout keys/content types, subcomposition, baseline profiles.
- iOS: framework size, Swift API shape, debug vs release framework builds, Xcode integration path.
- Runtime: redacted logs, crash breadcrumbs, performance telemetry, cold-start and first-screen timing where the app already has observability.
- Observability services: Datadog RUM, Bugsnag, Sentry, Firebase Crashlytics, CrashKiOS, NSExceptionKt, Kotzilla, Kermit, or Napier are optional project choices. Evaluate target support, privacy policy, symbolication, sampling, and operational ownership before adding one.
Guardrails
- Treat
kotlin.native.binary.gc=noopas a diagnostic-only setting, not a production fix. - Treat
smallBinaryand aggressive binary options as project-specific experiments with before/after measurement. - Do not add hot-reload, tracing, stability analyzer, or performance plugins unless the project already uses them or the user asks for that tooling.
- Do not benchmark debug Compose performance as production evidence.
- Do not add a third-party observability SDK when the request only needs a local performance diagnosis.
Output
For performance work, report:
- symptom and measurement surface
- suspected cause
- changed file or proposed change
- verification command
- before/after evidence when available
- residual risk and what would measure it