Kmp production governance

KMP Production Governance

Bundled commands use $PLUGIN_ROOT ($env:PLUGIN_ROOT in PowerShell; same path suffix) for the plugin root. Set it once: use the host's plugin-root variable when defined (Claude Code: PLUGIN_ROOT="$CLAUDE_PLUGIN_ROOT"), otherwise the absolute path of this plugin's root directory.

Use this skill for KMP build governance, production-readiness review, convention plugins, version catalogs, repository policy, module dependency hygiene, public API surface, library publishing, ABI validation, Klibs target support, and adoption risk.

Review Flow

1. Read settings.gradle(.kts), version catalogs, root build files, build-logic/buildSrc, module build files, and publishing configuration.
2. Run:

   python3 "$PLUGIN_ROOT/scripts/kmp_inspector.py" --root <project-root>
   

   Use --json --fail-on none when you need the readiness scorecard for a report.
3. Classify project role:
   • app-only shared code
   • internal shared mobile library
   • public KMP library
   • monorepo with many KMP modules
   • mixed native and shared UI application
4. Review governance before changing features.

Build Governance Dimensions

• Shared build logic: repeated module setup should move into role-based convention plugins when repetition is meaningful.
• Convention plugin boundary: keep role setup clear, not a dumping ground for stack choices.
• Version catalogs: centralize versions and aliases; avoid drift in module build files.
• Plugin management: centralize plugin resolution and repository policy in settings.
• Repository policy: avoid module-local repositories unless there is a documented reason.
• Module dependency hygiene: prefer implementation; use api only when consumers need exposed types.
• Public surface: keep shared/core modules small and intentional.
• Stack leakage: DI/database/obfuscation/publishing choices should not become universal defaults without product need.

Dependency Target Verification

Before recommending a library:

• Check official docs first.
• Use Klibs.io as a human verification surface for KMP target support when helpful.
• Confirm Maven coordinates and target variants.
• Fill the target matrix mentally or in notes: Android, iOS device, iOS simulator, JVM/Desktop, JS/Wasm, Native host targets.
• If any configured target is unsupported, keep the dependency out of commonMain.

Library Release Gates

For published KMP libraries, consider:

• API ownership: which packages/classes are public and stable.
• ABI validation: Kotlin Gradle Plugin abiValidation, checkKotlinAbi, and updateKotlinAbi when appropriate.
• Publication shape: Maven publications, Android target artifacts, iOS XCFramework or SwiftPM export.
• Unsupported target behavior: know whether ABI inference for locally unsupported targets is acceptable.
• Release notes: document source, binary, and Swift API compatibility impact.

Do not force ABI validation on private app modules. It is most useful when downstream consumers compile against your library.

Output

For reviews, lead with:

• production readiness verdict
• readiness scorecard areas from the inspector when available
• high/medium/low issues
• build governance gaps
• dependency target-support risks
• release/API risks
• exact validation commands
• deferred checks and why