reis-mobile 0.7.1 → 0.7.3

package/core/release/context.mjs

@@ -0,0 +1,11 @@
+import { join } from 'node:path';
+
+import { PLUGIN_ROOT } from '../paths.mjs';
+
+/** Detection suggests references, never proves store targets or release readiness. */
+export function releaseContext(detection) {
+  const platforms = detection.platforms.filter((platform) => ['android', 'ios'].includes(platform));
+  const references = detection.stack === 'unknown' ? [] : [...new Set([detection.stack, ...platforms])]
+    .map((stack) => join(PLUGIN_ROOT, 'skills/mobile-release/references', `${stack}.md`));
+  return { platforms, references, evidenceStatus: 'unverified', verdict: null };
+}

package/docs/agent-context.md

@@ -6,7 +6,7 @@ Read this contract once per task. If the caller supplied a brief, reuse it and v
 
 Use the CLI's resolved `Project` directory and stack/platform focus. Read repository instructions that apply to the files in scope, then relevant architecture docs, build manifests, lock files, nearby implementation and tests. In a monorepo, keep repository-wide constraints and app-specific conventions distinct. Skip generated files and unrelated features.
 
-If the repository contains `.reis-mobile/project.md`, read it for team knowledge that code cannot explain: product vocabulary, critical journeys, intentional boundaries and supported environments. This is optional Markdown read by the model, not a new CLI configuration key. Verify its file paths, symbols and commands against the current checkout; mark stale statements. Do not require a setup interview or create the file unless requested.
+If the repository contains `.reis-mobile/project.md`, read it for team knowledge that code cannot explain: product vocabulary, critical journeys, intentional boundaries and supported environments. In a monorepo with `.reis-mobile/config.yaml`, look beside that config; otherwise look under the resolved app root. This is optional Markdown read by the model, not a new CLI configuration key. Verify its file paths, symbols and commands against the current checkout; mark stale statements and distinguish team-authored business rules from facts inferred from code. Do not require a setup interview or create the file unless requested.
 
 ## Build a compact brief
 
@@ -33,7 +33,7 @@ Trace at least one concrete path through the relevant objects: an action to a st
 
 ## Optional team context
 
-A team can commit `.reis-mobile/project.md` alongside the existing `.reis-mobile/config.yaml` (which continues to support only `app`). Useful content is short and specific:
+A team can run `/reis-mobile:project [feature]` to create or refresh a verified object map in `.reis-mobile/project.md`, then add product knowledge that cannot be inferred from code. The command preserves team-authored text on refresh. The optional profile can live beside the existing `.reis-mobile/config.yaml` (which continues to support only `app`). Useful content is short and specific:
 
 ```markdown
 # Mobile project context

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "reis-mobile",
-  "version": "0.7.1",
-  "description": "AI agents and skills for mobile development — Flutter, Android, iOS and React Native — as a plugin for Claude Code and Codex: code review, debugging, tests, architecture, security and Firebase.",
+  "version": "0.7.3",
+  "description": "AI agents and skills for Flutter, Android, iOS, React Native and Kotlin Multiplatform — a Claude Code and Codex plugin for reviews, debugging, tests, architecture, security and Firebase.",
   "type": "module",
   "license": "MIT",
   "author": "Warleson Reis",
@@ -43,6 +43,7 @@
     "swift",
     "swiftui",
     "kotlin",
+    "kotlin-multiplatform",
     "jetpack-compose",
     "dart",
     "firebase",

package/skills/mobile-accessibility/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mobile-accessibility
-description: Audits and fixes accessibility in mobile apps on every stack — screen reader labels, roles, states and reading order for TalkBack and VoiceOver, decorative elements, grouping, touch target size, text scaling and Dynamic Type, color contrast, focus in dialogs and announcements for dynamic content — with the exact APIs for Flutter (Semantics), native Android (Jetpack Compose semantics and Views), native iOS (SwiftUI and UIKit) and React Native, plus automated checks in tests. Use when building or reviewing UI for accessibility, preparing an accessibility audit, fixing TalkBack or VoiceOver issues, or when the user mentions a11y, WCAG, screen readers, font scaling or contrast, even if they only point at one screen.
+description: Audits and fixes mobile accessibility across Flutter, native Android, native iOS, React Native and Kotlin Multiplatform, including shared Compose UI and native hosts. Covers TalkBack/VoiceOver labels, roles, state, reading order, touch targets, text scaling, contrast and focus. Use for a11y audits, screen-reader bugs or accessible UI implementation.
 intents: [accessibility]
 stacks: ["*"]
 ---
@@ -17,6 +17,7 @@ One accessibility process for every mobile stack. This file holds what is true e
 | Native Android: Jetpack Compose or Views | [references/android.md](references/android.md) |
 | Native iOS: SwiftUI or UIKit | [references/ios.md](references/ios.md) |
 | React Native or Expo | [references/react-native.md](references/react-native.md) |
+| Kotlin Multiplatform with shared Compose UI or native host UI | [references/kotlin-multiplatform.md](references/kotlin-multiplatform.md) |
 
 In Flutter and React Native apps, the native reference applies only to screens or components written natively (platform views, native modules with UI).
 

package/skills/mobile-accessibility/references/flutter.md

@@ -27,7 +27,7 @@ Pitfalls:
 ## Announcements and focus
 
 - Mark text that changes on its own (a counter, a status) with `Semantics(liveRegion: true, ...)`.
-- For one-off messages, `SemanticsService.announce(message, textDirection)` exists in `package:flutter/semantics.dart`; check its status in the Flutter version in `pubspec.lock`'s SDK constraint before recommending it, since the announcement APIs have been evolving for multi-view support.
+- For one-off messages, inspect the installed Flutter SDK's `SemanticsService` API and the project's SDK pin before recommending an announcement call; `pubspec.lock` does not identify the exact Flutter SDK version.
 - `SnackBar`s shown through `ScaffoldMessenger` are announced by the framework.
 - Dialogs opened with `showDialog` and routes block the semantics of what is behind them; custom overlays built with `Stack` and `Positioned` do not — use `BlockSemantics` or a route.
 - Control reading order with `Semantics(sortKey: OrdinalSortKey(n))` only when the visual order and the widget order genuinely differ.

package/skills/mobile-accessibility/references/kotlin-multiplatform.md

@@ -0,0 +1,9 @@
+# Kotlin Multiplatform accessibility
+
+Determine whether the changed screen is shared Compose Multiplatform UI, native Android UI, native SwiftUI/UIKit, or a mix. KMP shared domain code has no accessibility tree by itself.
+
+- For shared Compose UI, inspect semantics and state on the actual component, then verify the Android and iOS host experience with TalkBack and VoiceOver. Check the installed Compose version's iOS accessibility behavior against [JetBrains' iOS accessibility guide](https://kotlinlang.org/docs/multiplatform/compose-ios-accessibility.html).
+- For native host UI, use the [Android](android.md) or [iOS](ios.md) reference and inspect the adapter that turns a shared state/error into labels, announcements and focus transitions.
+- Test the same critical journey on both targets at large text sizes. A shared composable test does not prove native screen-reader behavior on either device.
+
+Give **screen path:symbol → rendered target UI → missing name/role/state/order or focus behavior → target-specific fix → verification**. If a target UI is absent, report that fact instead of claiming parity.

package/skills/mobile-architecture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mobile-architecture
-description: Designs and reviews the architecture of mobile apps on every stack — layers (UI, domain, data), unidirectional data flow, state ownership and state management, feature-first modularization, dependency injection, navigation, offline data and use cases — for Flutter (BLoC, Riverpod, Provider, ChangeNotifier), native Android (ViewModel, Hilt, Gradle modules), native iOS (SwiftUI and UIKit, Observation, Swift packages, actors) and React Native (server vs client state, React Navigation, Expo Router, native modules). Use when structuring a new app or feature, choosing or implementing state management, refactoring to layers or modules, or when the user asks where code should live, even if they only mention one class or screen.
+description: Designs and reviews mobile architecture across Flutter, native Android, native iOS, React Native and Kotlin Multiplatform. Covers state ownership, data flow, modules, dependency boundaries, navigation, offline data and KMP shared source sets versus host apps. Use when structuring a feature, choosing state management, refactoring layers or deciding where a real class or screen belongs.
 intents: [architecture]
 stacks: ["*"]
 ---
@@ -17,6 +17,7 @@ What makes a mobile codebase keep up with its team, and how each stack expresses
 | Native Android (Kotlin), or the Android side of Kotlin Multiplatform | [references/android.md](references/android.md) |
 | Native iOS (Swift) | [references/ios.md](references/ios.md) |
 | React Native or Expo | [references/react-native.md](references/react-native.md) |
+| Kotlin Multiplatform shared code and target boundaries | [references/kotlin-multiplatform.md](references/kotlin-multiplatform.md) |
 
 ## 2. Map before judging
 

package/skills/mobile-architecture/references/kotlin-multiplatform.md

@@ -0,0 +1,11 @@
+# Kotlin Multiplatform architecture
+
+Read the [KMP source-set guide](../../mobile-kmp/references/source-sets.md) before assigning a responsibility to shared or target code.
+
+1. Draw the actual module and source-set graph from Gradle configuration. Mark `commonMain`, intermediate sets, target sets and the Android/iOS host entry points that consume the module. Do not infer a shared UI from the KMP plugin.
+2. Trace one user action through each host into the same shared domain object. Record the state owner, repository or use-case interface, platform adapter, persistence model and error conversion. Include the Swift-facing API if iOS calls shared Kotlin.
+3. Put platform-neutral rules and data contracts in shared code only when both callers need the same behavior. Keep lifecycle, permissions, UI navigation and platform SDK setup with their actual owners. For small platform operations, compare an `expect`/`actual` seam with an injected interface; follow the project's existing pattern.
+4. Specify object mappings at API and persistence boundaries, especially nullability and error types exported to Swift. Name who writes each object and which cache is authoritative.
+5. Return a table of **object/symbol → source set → owner → Android caller → iOS caller → test seam**, plus a minimal migration sequence. Mark proposed paths as proposed.
+
+Check [Kotlin's source-set hierarchy](https://kotlinlang.org/docs/multiplatform/multiplatform-dsl-reference.html) and [platform API connection guidance](https://kotlinlang.org/docs/multiplatform/multiplatform-connect-to-apis.html) against the installed Kotlin version.

package/skills/mobile-code-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mobile-code-review
-description: Reviews mobile code for the bugs that reach production on every stack — Flutter and Dart (pull request checklist, widget lifecycle and rebuilds, project health, static analysis), native Android (Kotlin, coroutines, Jetpack Compose, lifecycle), native iOS (Swift concurrency, SwiftUI, retain cycles) and React Native (hooks, re-renders, platform code, Expo) — with file:line evidence and a structured report. Use whenever the user asks for a code review, PR or merge request review, project audit or quality check of a mobile app, or runs /reis-mobile:review, even if they only point at a diff or a folder.
+description: Reviews mobile code for production bugs across Flutter, native Android, native iOS, React Native and Kotlin Multiplatform, including KMP source-set and host API contracts. Covers lifecycle, concurrency, UI state and native boundaries with file:line evidence. Use for a code review, PR, project audit, quality check or /reis-mobile:review.
 intents: [review, performance]
 stacks: ["*"]
 ---
@@ -19,6 +19,7 @@ Detect the stack first, then apply the platform checklist to the files in scope:
 | Native Android (Kotlin/Java), or the Android side of Kotlin Multiplatform | [references/android.md](references/android.md) |
 | Native iOS (Swift/Objective-C) | [references/ios.md](references/ios.md) |
 | React Native or Expo | [references/react-native.md](references/react-native.md) |
+| Kotlin Multiplatform shared and target changes | [references/kotlin-multiplatform.md](references/kotlin-multiplatform.md) |
 
 In a cross-platform app, native code in `android/`, `ios/` or native modules gets the native checklist too. Security findings follow `mobile-security` when it is loaded.
 

package/skills/mobile-code-review/references/flutter/widget-review.md

@@ -23,7 +23,7 @@ Apply to Dart files with widgets (`StatelessWidget`, `StatefulWidget`, `Consumer
 - [ ] Long lists with `ListView(children: [...])` / `Column` inside `SingleChildScrollView`: use `ListView.builder` or `SliverList`.
 - [ ] `shrinkWrap: true` on a large list inside another scroll view: forces layout of every item.
 - [ ] Rebuild scope too large: `setState`, `BlocBuilder` or `Consumer` at the top of the screen when only one part changes. Use `buildWhen`, `select` or extract the widget.
-- [ ] `MediaQuery.of(context)` used only for the size: `MediaQuery.sizeOf(context)` rebuilds less. Confirm the Flutter version in `pubspec.lock` before suggesting it.
+- [ ] `MediaQuery.of(context)` used only for the size: `MediaQuery.sizeOf(context)` rebuilds less. Confirm the project's Flutter SDK pin or installed toolchain before suggesting it.
 - [ ] Network images without `cacheWidth`/`cacheHeight` or without caching, decoded at full resolution to display thumbnails.
 - [ ] Animated `Opacity` or `ClipRRect`/`BackdropFilter` in list items: prefer `FadeTransition`/`AnimatedOpacity` and avoid unnecessary clipping.
 - [ ] Heavy work (parsing large JSON, cryptography, image processing) on the UI thread: use `compute`/`Isolate.run`.

package/skills/mobile-code-review/references/flutter.md

@@ -13,6 +13,6 @@ Apply the checklists in this order; stop early for a small diff that only touche
 
 - Dart style and idioms: the Effective Dart and Dart 3 guides in the `mobile-flutter` skill (`references/dart.md`).
 - Follow the project's state management (BLoC/Cubit, Riverpod, Provider) instead of suggesting another one.
-- Check the Flutter and Dart versions in `pubspec.lock` before recommending newer APIs (`MediaQuery.sizeOf`, Dart 3 patterns).
+- Check the Flutter SDK pin or installed toolchain before recommending newer APIs (`MediaQuery.sizeOf`, Dart 3 patterns); `pubspec.lock` records dependency resolution, not the exact Flutter SDK version.
 - Generated files (`*.g.dart`, `*.freezed.dart`, `*.mocks.dart`) are reviewed through their source annotations, not line by line.
 - Native code under `android/` and `ios/` follows [android.md](android.md) and [ios.md](ios.md).

package/skills/mobile-code-review/references/kotlin-multiplatform.md

@@ -0,0 +1,11 @@
+# Kotlin Multiplatform review
+
+Read the changed module's source-set graph and all configured target implementations. Review the public contract as it is consumed by Android and the Swift/iOS host.
+
+- **Shared logic:** check that DTO/domain conversions, error mapping, coroutine ownership and repository state remain target-neutral. Cite the exact shared symbol and affected caller.
+- **Target completeness:** compare every changed `expect` declaration and actual implementation or injected adapter across configured targets. Check target-only dependencies are declared in the correct source set.
+- **iOS boundary:** inspect framework export, Swift nullability/error handling and callback or coroutine lifetime when a shared API changes. A shared Kotlin compile alone does not validate the Swift caller.
+- **UI boundary:** first determine whether the project shares Compose UI. Review the Android/iOS host lifecycle and accessibility in the correct native or Compose reference.
+- **Tests:** look for common tests for the rule and target/host tests where behavior depends on platform services. Verify that CI actually runs the relevant target tasks.
+
+Return only reproducible findings at `path:line`, with the affected target and smallest fix. Use the [source-set guide](../../mobile-kmp/references/source-sets.md) for the dependency graph.

package/skills/mobile-debug/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mobile-debug
-description: Finds the cause of failing builds and runtime errors in mobile apps on every stack — Flutter (pub version solving, Dart compilation, generated code, layout overflows, runtime exceptions), native Android (Gradle, AGP, JDK and Kotlin mismatches, dependency conflicts, manifest merger, R8, logcat crashes, ANRs and memory leaks), native iOS (Xcode signing and provisioning, deployment targets, CocoaPods, Swift Package Manager, crash logs) and React Native (Metro, native modules not found, Hermes, the Android and iOS builds underneath), plus deep links, App Links and Universal Links that do not open the app. Use whenever a build, `flutter run`, `pod install`, Gradle task, Xcode archive or app launch fails, when the user pastes a stack trace, "BUILD FAILED" or a red screen, or runs /reis-mobile:debug, even if they only paste the error.
+description: Diagnoses build and runtime failures across Flutter, native Android, native iOS, React Native and Kotlin Multiplatform. Covers pub/Dart, Gradle/AGP, Xcode/CocoaPods, Metro, KMP source sets and iOS frameworks, crashes and deep links. Use for failing builds, app launches, stack traces or /reis-mobile:debug.
 intents: [debug, build, dependency, migration]
 stacks: ["*"]
 ---
@@ -19,6 +19,7 @@ Choose by the stack **and** by the layer the error comes from — a Flutter or R
 | Gradle, the Android build, logcat crashes or ANRs (native Android, or the `android/` folder of any app) | [references/android.md](references/android.md) |
 | Xcode, signing, CocoaPods, Swift packages or iOS crash logs (native iOS, or the `ios/` folder of any app) | [references/ios.md](references/ios.md) |
 | A React Native or Expo app: Metro, native modules, JavaScript errors | [references/react-native.md](references/react-native.md) |
+| Kotlin Multiplatform compilation, source-set or framework integration | [references/kotlin-multiplatform.md](references/kotlin-multiplatform.md) |
 | A deep link, App Link or Universal Link that opens the browser, the wrong screen or crashes (any stack) | [references/deep-links.md](references/deep-links.md) |
 
 When `reis-mobile debug` (or `/reis-mobile:debug`) ran, its `area` line points at the layer: `gradle`, `manifest`, `proguard` → Android; `xcode`, `signing`, `cocoapods`, `spm` → iOS; `pub` → Flutter; `metro` → React Native.

package/skills/mobile-debug/references/kotlin-multiplatform.md

@@ -0,0 +1,10 @@
+# Kotlin Multiplatform debugging
+
+Find the first failing module, Gradle task, compilation and target in the log. Read `settings.gradle.kts`, the affected `build.gradle.kts`, version catalog and source-set directories before suggesting a fix.
+
+1. For an unresolved symbol, check whether its dependency and declaration belong to `commonMain`, an intermediate source set or a target source set. Confirm that the failing target actually depends on that set.
+2. For `expect`/`actual` errors, compare declarations and implementations for every configured target; follow the installed Kotlin compiler's message rather than assuming a missing iOS file.
+3. For an iOS framework or Xcode failure, separate Kotlin framework compilation/linking from the Swift host build, then inspect the project's integration method and selected architecture. Use the [Apple integration guide](../../mobile-kmp/references/apple-interop.md).
+4. For an Android failure, apply the [Android debugging reference](android.md) to the host/module. For a native iOS failure, apply the [iOS reference](ios.md) to the host. A shared-source error remains a KMP issue.
+
+Report the first error line, affected source set/target, configuration evidence and the exact project task that reproduces it. Discover task names from the wrapper instead of guessing them. Kotlin's [source-set reference](https://kotlinlang.org/docs/multiplatform/multiplatform-dsl-reference.html) defines the hierarchy.

package/skills/mobile-firebase/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mobile-firebase
-description: Integrates Firebase into mobile apps on every stack — Flutter (FlutterFire), native Android (Kotlin), native iOS (Swift) and React Native (React Native Firebase) — covering project setup, Authentication, Cloud Firestore, Realtime Database, Cloud Storage, callable Cloud Functions, Cloud Messaging push notifications, Analytics, Crashlytics, Remote Config, App Check, In-App Messaging, AI Logic and SQL Connect (formerly Data Connect). Use whenever the user adds, configures, debugs or reviews any Firebase product in a mobile app, including google-services.json, GoogleService-Info.plist, FCM tokens, security rules and the Firebase Local Emulator Suite, even if they only name the product.
+description: Integrates and reviews Firebase across Flutter, native Android, native iOS, React Native and Kotlin Multiplatform. Covers Auth, databases, Storage, Functions, FCM, Analytics, Crashlytics, Remote Config, App Check and KMP shared-to-platform SDK boundaries. Use for any Firebase setup, bug, security rule, emulator, configuration file or product integration.
 routing: manual
 stacks: ["*"]
 ---
@@ -19,6 +19,7 @@ Detect the stack first, then read the platform guide (shared setup and the produ
 | Native Android (Kotlin), or the Android side of Kotlin Multiplatform | [references/android.md](references/android.md) |
 | Native iOS (Swift) | [references/ios.md](references/ios.md) |
 | React Native or Expo | [references/react-native.md](references/react-native.md) |
+| Kotlin Multiplatform shared API and Android/iOS Firebase boundaries | [references/kotlin-multiplatform.md](references/kotlin-multiplatform.md) |
 
 In a Flutter or React Native app, native code in `android/` and `ios/` (a notification service, an app extension) follows the native guides.
 

package/skills/mobile-firebase/references/kotlin-multiplatform.md

@@ -0,0 +1,10 @@
+# Firebase in Kotlin Multiplatform
+
+Start with the installed Gradle dependencies and source sets. Do not assume a Firebase SDK is available to `commonMain`, or that Android and iOS use the same API surface. Identify the actual Firebase wrapper and platform initialization in this repository.
+
+1. Map each requested product operation to a shared interface or target implementation, the Android Firebase setup and the iOS Firebase setup. Record who owns listeners, token refresh and error conversion.
+2. Verify target dependency availability against the installed library and version. If a third-party KMP wrapper is used, inspect its target support and native integration before moving a call into shared code.
+3. Keep each host's configuration, push notification entitlement/permission and lifecycle handling in that host. Read the [Android](android.md) or [iOS](ios.md) product reference only for the affected target.
+4. Test shared mapping against fakes, then test each real target's configuration or emulator setup separately. Do not treat a `commonTest` pass as proof of FCM delivery or native SDK setup.
+
+Report **product → shared symbol → Android implementation/config → iOS implementation/config → verification**, marking unsupported or unverified targets explicitly. Check [Kotlin's platform API guidance](https://kotlinlang.org/docs/multiplatform/multiplatform-connect-to-apis.html) for the boundary options.

package/skills/mobile-flutter/SKILL.md

@@ -26,5 +26,5 @@ Each topic file lists its guides; open only the ones the task needs.
 ## Before writing code
 
 - Follow the project: its state management, folder structure, lints and packages already in `pubspec.yaml`.
-- Check the Flutter and Dart versions in `pubspec.lock` before using newer APIs; guides may describe features that a pinned SDK does not have.
+- Check the Flutter SDK pin (`.fvmrc`, toolchain config or CI) and the installed `flutter --version` before using newer APIs; `pubspec.lock` records resolved packages, not the exact Flutter SDK version.
 - Prefer packages the project already depends on over adding new ones; when adding one, check that it supports every platform the app targets.

package/skills/mobile-kmp/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: mobile-kmp
+description: Works on Kotlin Multiplatform mobile projects with shared Kotlin source sets and Android/iOS targets. Use for architecture, tests, debugging, reviews, performance, security, accessibility, dependencies and releases when `org.jetbrains.kotlin.multiplatform` is applied; inspect actual targets, `commonMain`/`commonTest`, target source sets, Compose Multiplatform and the iOS framework/host app before giving platform advice.
+intents: [architecture, test, performance, review, debug, security, release, accessibility, migration, dependency, build, deployment]
+stacks: [kotlin-multiplatform]
+---
+
+# Kotlin Multiplatform
+
+KMP is a sharing mechanism, not a promise that both apps use the same UI or SDK. Resolve the module and target graph before choosing Android, iOS or shared-code guidance.
+
+| Question | Read |
+|---|---|
+| Which code and dependencies can be shared? | [references/source-sets.md](references/source-sets.md) |
+| How does shared Kotlin reach the iOS app? | [references/apple-interop.md](references/apple-interop.md) |
+| Is UI shared with Compose Multiplatform or native on each target? | [references/compose-ui.md](references/compose-ui.md) |
+| Which build, measurement or release task applies? | [references/build-performance.md](references/build-performance.md) |
+
+## Ground the answer
+
+1. Read `settings.gradle.kts`, the affected module's `build.gradle.kts`, version catalog and source-set directories. Record the configured targets; `androidMain` and `iosMain` are not proof that a target is built in CI.
+2. Trace a real symbol from `commonMain` through an interface or `expect` declaration to each configured implementation and its Android/iOS caller. Name the module, source set and owner at every boundary. For shared Compose UI, trace its host entry too.
+3. Match validation to the changed boundary: shared Kotlin tests on configured targets, target tests for `actual` implementations, and host UI/device tests for behavior that crosses into Android or iOS. A JVM test is not iOS coverage.
+4. Use the topic skill for the requested work. Use `mobile-android` or `mobile-ios` only for an affected host or target-specific implementation; do not apply native-app instructions blindly to `commonMain`.
+
+The [Kotlin Multiplatform source-set reference](https://kotlinlang.org/docs/multiplatform/multiplatform-dsl-reference.html) defines `commonMain`, `commonTest` and target compilations. Confirm DSL and task names in the project's installed Kotlin and Gradle versions.

package/skills/mobile-kmp/references/apple-interop.md

@@ -0,0 +1,9 @@
+# iOS host and framework integration
+
+Locate the iOS app target, scheme and the shared framework declaration in the KMP build. Determine whether the app integrates it through an Xcode build phase, a local/remote Swift package, CocoaPods or another checked-in path. Trace the same Kotlin API to its Swift call and back through errors, callbacks or state observation.
+
+For an iOS build failure, separate Kotlin/Native compilation, framework export/linking, Xcode signing and Swift source errors. Inspect the actual build phase and artifact path before changing Gradle or Pods. Match architecture, configuration and framework version to the failing simulator or device. For a release, verify the framework embedded in the signed app matches the shared module revision and preserve the app's existing symbol upload path.
+
+An iOS simulator test of shared Kotlin does not exercise the Swift app's navigation, permissions or VoiceOver. Use the iOS topic reference when the changed behavior lives in the host.
+
+Reference: [official iOS integration methods](https://kotlinlang.org/docs/multiplatform-ios-integration-overview.html).

package/skills/mobile-kmp/references/build-performance.md

@@ -0,0 +1,9 @@
+# Build, profiling and delivery
+
+List Gradle tasks for the affected module and configured target before naming a command. Use the wrapper, version catalog and CI matrix as the source of the Kotlin, Gradle, Compose and Android plugin versions. A compilation failure in `commonMain` affects all targets; an `ios*` link failure or Android variant failure has a narrower owner.
+
+For performance, identify whether the cost is shared algorithm work, Android UI, iOS host/Compose UI or framework crossing. Measure the same journey and input on each affected target with that target's profiler and release-like configuration; do not infer iOS frame time from JVM or Android traces. Attribute retained state to the shared object, native host or bridge that owns it.
+
+For delivery, trace Android artifact and iOS archive separately to their app IDs, signing, symbols and store workflow. The shared library is an input to both; publishing one platform does not publish the other. Preserve the host app's rollout and rollback process.
+
+References: [KMP test tasks and reports](https://kotlinlang.org/docs/multiplatform-run-tests.html), [iOS framework integration](https://kotlinlang.org/docs/multiplatform-ios-integration-overview.html).

package/skills/mobile-kmp/references/compose-ui.md

@@ -0,0 +1,9 @@
+# Shared UI versus native UI
+
+First find where the screen is implemented. A KMP app may share only logic and render with Jetpack Compose on Android and SwiftUI/UIKit on iOS, or share UI with Compose Multiplatform. Do not apply Compose tests or semantics to a native Swift screen.
+
+For shared Compose UI, trace the screen's state owner, Composable entry, navigation owner and the Android/iOS host that installs it. Keep platform services behind the project's existing boundary. Inspect resource generation and the source set holding each resource; Android `R` resources and Compose Multiplatform `Res` accessors are different APIs.
+
+For accessibility, inspect Compose semantics and verify them on both targets with TalkBack/VoiceOver. For target-specific dialogs, text input, insets or navigation, inspect the native host as well. Verify API availability against the installed Compose Multiplatform version.
+
+References: [Compose resources](https://kotlinlang.org/docs/multiplatform/compose-multiplatform-resources.html), [iOS accessibility](https://kotlinlang.org/docs/multiplatform/compose-ios-accessibility.html).

package/skills/mobile-kmp/references/source-sets.md

@@ -0,0 +1,9 @@
+# Shared-code boundaries
+
+Read the actual `kotlin {}` targets and `sourceSets {}` dependency graph. Identify `commonMain`, intermediate source sets (such as `iosMain`) and target sources. A file's folder does not establish that every configured binary includes it; check `dependsOn` and the target hierarchy.
+
+For a requested feature, record the shared public type, its caller on each target, input/output values and error/cancellation contract. Keep pure business rules and serialization in common code when all targets use the same contract. Put platform SDK calls behind a small common interface or `expect`/`actual` declaration; confirm every configured target has the implementation. Prefer the project's existing injection pattern rather than adding a second one.
+
+When a shared type is exported to Swift, check the actual framework API and conversion at the call site. Kotlin nullability, exceptions, collections and asynchronous work can have a different Swift-facing shape from the Kotlin call. Do not infer that a Kotlin unit test covers the Swift consumer.
+
+References: [source-set DSL](https://kotlinlang.org/docs/multiplatform/multiplatform-dsl-reference.html), [platform APIs and interfaces](https://kotlinlang.org/docs/multiplatform/multiplatform-connect-to-apis.html).

package/skills/mobile-release/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mobile-release
-description: Prepares and checks mobile app releases on every stack — release readiness (go/no-go) checklist, version name and build number, signing, crash symbols (R8 mappings, dSYMs, Dart split debug info, JavaScript source maps), store requirements, staged rollout and rollback, release notes and store listing copy with the Google Play and App Store character limits, and CI/CD pipelines with GitHub Actions, fastlane and EAS — for Flutter, native Android, native iOS and React Native. Use when preparing a version for Google Play or the App Store, auditing whether a build is ready to ship, writing release notes or store descriptions from the git history, setting up or reviewing a build and deploy pipeline, or planning a rollout, even if the user only says "we ship on Friday".
+description: Prepares mobile releases across Flutter, native Android, native iOS, React Native and Kotlin Multiplatform, including separate Android/iOS artifacts from a shared KMP revision. Covers versions, signing, symbols, store readiness, rollout, release notes and CI/CD. Use for release audits, store submission, build pipelines or rollout planning.
 intents: [release, deployment]
 stacks: ["*"]
 ---
@@ -13,10 +13,12 @@ One release process for every mobile stack. This file holds the process and what
 
 | Need | Read |
 |---|---|
+| Evidence-backed readiness audit, verdict and report | [references/readiness.md](references/readiness.md) |
 | Flutter app | [references/flutter.md](references/flutter.md) |
 | Native Android, or the Android build of any app | [references/android.md](references/android.md) |
 | Native iOS, or the iOS build of any app | [references/ios.md](references/ios.md) |
 | React Native or Expo app | [references/react-native.md](references/react-native.md) |
+| Kotlin Multiplatform shared module and both host apps | [references/kotlin-multiplatform.md](references/kotlin-multiplatform.md) |
 | Release notes and store listing text | [references/store-copy.md](references/store-copy.md) |
 | A CI/CD pipeline that builds, signs and uploads | [references/ci-cd.md](references/ci-cd.md) |
 
@@ -24,11 +26,13 @@ Flutter and React Native apps also need the Android and iOS references for signi
 
 ## 2. Readiness checklist
 
-Check each item against the project, not against memory. Mark each one **pass**, **fail** (with `file:line` or the missing artifact) or **unknown** (needs information only the team has, such as the store console state).
+For readiness audits, first follow [the readiness contract](references/readiness.md): resolve each artifact identity, collect per-target evidence and apply its required gates and deterministic verdict helper.
+
+Check each item against the project, not against memory. For the readiness verdict, a missing artifact or unavailable check is **unknown**; use **fail** only for an observed failure with evidence. Record a source reference and next action for every gate.
 
 **Version**
-- [ ] The version name follows the project's scheme and changed since the last release tag (`git describe --tags --abbrev=0`).
-- [ ] The build number is higher than any build already uploaded. Both stores reject a build number they have seen.
+- [ ] The version name follows the app's actual versioning scheme and is verified in the artifact and applicable CI overrides.
+- [ ] The build number satisfies the destination store’s numbering scope, verified against upload history: Android versionCode increases across tracks; iOS build numbers must be unused within the applicable version train. See the native references.
 - [ ] Android, iOS and any cross-platform manifest (`pubspec.yaml`, `app.json`) agree on the version.
 
 **Build quality**
@@ -46,25 +50,10 @@ Check each item against the project, not against memory. Mark each one **pass**,
 **Rollout**
 - [ ] Staged rollout (Play) or phased release (App Store) planned for updates, with the crash-free and ANR metrics to watch and the threshold that halts it.
 - [ ] Rollback plan: stores do not roll back a binary. Halting a rollout stops new installs; users who updated need a new build with a higher build number, a server-side kill switch or a remote config flag. Know which one applies before shipping.
-- [ ] The release commit is tagged and the tag matches the version.
+- [ ] The release commit is tagged and the tag matches the version, when this is the project's release convention.
 
 ## 3. Report
 
-```markdown
-## Release readiness — <app> <version> (<build>)
-Verdict: GO | GO WITH RISKS | NO-GO
-
-### Blockers
-- item — evidence (file:line or missing artifact) — fix
-
-### Risks
-- item — why it matters — mitigation
-
-### Unknown
-- item — who or what can confirm it
-
-### Rollout plan
-Stages, metrics to watch, halt threshold, rollback path.
-```
+Use the [readiness report and decision rules](references/readiness.md#report). Any failed or unknown required gate means **NO-GO**. **GO WITH RISKS** requires all gates to pass with explicitly documented non-blocking risks; **GO** requires no outstanding risks.
 
-A single blocker makes the verdict NO-GO. Do not bump versions, create tags, upload builds or change store settings unless the user asks; propose the exact commands instead.
+Readiness audits inspect existing evidence without running builds/tests or modifying the app. Version bumps, tags, uploads and store changes follow the user's explicit execution scope and existing authorization.

package/skills/mobile-release/references/kotlin-multiplatform.md

@@ -0,0 +1,12 @@
+# Kotlin Multiplatform release
+
+A shared module revision can affect two separate app artifacts. Inventory the Android application, iOS host project and framework integration that this repository actually ships.
+
+| Boundary | Verify |
+|---|---|
+| Shared module | Exact commit/version consumed by both hosts, configured target builds and common/target tests. |
+| Android app | Version/build number, signing, release variant, R8 mapping and Play rollout using the [Android guide](android.md). |
+| iOS app | Host version/build number, framework architecture, archive/signing, dSYM and App Store rollout using the [iOS guide](ios.md). |
+| CI | Both artifacts built from the intended shared revision; host tests and upload jobs are distinguished from framework compilation. |
+
+Record **artifact → shared revision → build/test evidence → signing/symbol evidence → rollout owner**. One target passing does not make the other ready. Use the [Apple integration guide](../../mobile-kmp/references/apple-interop.md) to identify the framework path, and confirm current store requirements in each store's official portal.

package/skills/mobile-release/references/readiness.md

@@ -0,0 +1,88 @@
+# Evidence-backed readiness audit
+
+Use this contract for `/reis-mobile:release` and any readiness request. Other release tasks (store copy, pipeline implementation, deployment) retain their requested scope.
+
+## Release identity and target coverage
+
+For every intended artifact, record **app/package or bundle ID → flavor/scheme/environment → version/build → source revision → store/track → built artifact** with evidence. Inspect build overrides, CI parameters and artifact metadata; distinguish configured values from values verified in the binary. A directory or configured KMP target does not prove a shippable host exists. A shared framework is not an iOS app archive.
+
+Use detection as an inventory, then confirm actual Android/iOS hosts and requested destinations. Flutter, React Native/Expo and KMP shipping to both stores need separate gate rows for both artifacts. A prompt focusing on Android does not silently approve the iOS artifact. If the user explicitly limits the audit to one store, state the exclusion and do not issue a combined verdict. Expo can generate native folders: inspect app configuration and EAS profiles without running prebuild. Unknown targets or missing binaries stay unknown.
+
+Read the stack reference plus [android.md](android.md) and/or [ios.md](ios.md) for the actual destinations. KMP also needs [kotlin-multiplatform.md](kotlin-multiplatform.md). Do not substitute a shared-code test for a native host test.
+
+## Required gates
+
+Each target has these gate IDs. Every gate is **pass**, **fail**, or **unknown**, with a source reference and an exact next action/owner when unresolved. A failed check needs observed failure evidence; unavailable evidence is unknown. A local config file proves configuration only, not an executed check, successful upload, current console state or store approval.
+
+| ID | Evidence required |
+|---|---|
+| `identity` | All identity fields above, including artifact provenance and agreement with the intended source revision. Record dirty/untracked source and unknown CI overrides. |
+| `build` | Successful release build log/CI job for this revision and artifact, with the actual variant and production environment. A workflow YAML or debug build is insufficient. |
+| `tests` | Actual results for applicable unit/integration/device checks on this revision, with counts and skipped/failed checks. Resolve required suites from project policy and the changed behavior. |
+| `analysis` | Actual lint/static-analysis results for the release revision and applicable targets. Missing tools or logs are unknown, not pass. |
+| `version` | Artifact version/build matched to source/CI inputs and store upload history, applying the platform's numbering scope. Verify the previous release using the project's convention, not merely the closest tag. See [Android versioning](https://developer.android.com/studio/publish/versioning) and [Apple's build identification](https://developer.apple.com/help/app-store-connect/reference/app-information/app-information). |
+| `signing` | Signed artifact verification, intended distribution identity, and applicable entitlements/profile or upload-key setup. Never read or print private keys, passwords or tokens. |
+| `symbols` | Matching R8/native symbols, dSYMs, Dart debug info and/or JS source maps, with archive/upload evidence as required by the app. Verify build IDs/UUIDs or provenance. |
+| `store` | Current official requirement URL and access date, target SDK/toolchain evidence, and any account/track eligibility or review state needed for the intended action. Unavailable portal confirmation stays unknown. |
+| `privacy` | Permissions/data collection and third-party SDK inventory reconciled with manifests, usage descriptions, privacy policy and store disclosures. Local declarations alone do not prove console forms agree. |
+| `listing` | Required locales, release notes/screenshots/metadata, and reviewer access where applicable. Account secrets never enter the report. |
+| `rollout` | Owner, stages, monitoring signals and halt thresholds, plus a verified halt/kill-switch/higher-build hotfix path. Mark proposed thresholds as proposals until accepted. A halt does not revert installed binaries. See [Play staged rollouts](https://support.google.com/googleplay/android-developer/answer/6346149) and [Apple phased releases](https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases); confirm their current behavior before planning recovery. |
+
+If a requirement within a gate does not apply (for example no R8 mapping when R8 is disabled), cite evidence and the reason; do not omit the gate. A gate can pass with a justified non-applicability statement only after verifying all of its applicable requirements. No gate is waived simply to obtain GO.
+
+Current store rules must be checked against official sources, such as [Google Play target API requirements](https://support.google.com/googleplay/android-developer/answer/11926878) and [Apple's upcoming requirements](https://developer.apple.com/news/upcoming-requirements/). State the exact unresolved confirmation if browsing or store access is unavailable. Do not reuse a date or minimum SDK from memory.
+
+## Decision rule
+
+- **NO-GO:** any required gate fails, is unknown, is missing, or has no supporting evidence. Missing targets also block. Distinguish observed failures from missing verification.
+- **GO WITH RISKS:** every required gate passes and explicitly documented non-blocking risks remain. A risk cannot waive an unresolved required gate.
+- **GO:** every required gate passes and there are no outstanding risks.
+
+The combined verdict covers every included target; one platform passing cannot approve another.
+
+Use [the verdict helper](../scripts/verdict.mjs) to check the report's decision. It validates completeness and consistency, **not the truth of the evidence or whether a risk is truly non-blocking**. Supply JSON on stdin using a quoted heredoc delimiter (no shell expansion):
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/skills/mobile-release/scripts/verdict.mjs" <<'REIS_RELEASE_EVIDENCE'
+{"targets":[{"target":"android:production","gates":[{"id":"build","status":"unknown","evidence":[],"nextAction":"Release owner: provide the release CI job and artifact for the requested revision."}]}],"risks":[]}
+REIS_RELEASE_EVIDENCE
+```
+
+This intentionally incomplete example returns NO-GO. Replace it with the actual targets and all 11 gates; use one target name per artifact/store/track combination. `evidence` is an array of non-empty references (`file:line`, command plus result/log, artifact metadata, CI URL or dated portal confirmation). `nextAction` explains what resolves each fail/unknown. `risks` is an optional array of objects with `id`, `description`, evidence references, `mitigation` and `owner`; include only evidenced issues whose impact truly does not block the release. The auditor is responsible for that classification. Do not place secrets in JSON. Choose a heredoc delimiter absent from the payload. The helper writes only stdout; exit 0 means evaluation succeeded, **not** GO. Malformed input exits 1 and must be corrected before reporting a verdict. Preserve returned unknowns and blockers; do not manually upgrade the result.
+
+## Report
+
+Write in the requested language; keep gate IDs and verdict identifiers stable.
+
+```markdown
+## Release readiness — <app> <version/build>
+Verdict: GO | GO WITH RISKS | NO-GO
+Scope: <included artifacts/stores/tracks and explicit exclusions>
+
+### Release identity
+| Target | App ID | Variant/environment | Version/build | Revision | Store/track | Artifact | Evidence |
+|---|---|---|---|---|---|---|---|
+
+### Gates
+| Target | Gate | Status | Evidence / missing confirmation | Next action / owner |
+|---|---|---|---|---|
+
+### Blockers
+Observed failures and unverified required gates, separately identified.
+
+### Risks
+Non-blocking risks, mitigation and owner.
+
+### Unknowns
+Missing evidence and the exact external confirmation needed.
+
+### Next actions
+Ordered resolution steps; commands prepared versus commands actually executed.
+
+### Rollout and rollback
+Stages, signals, thresholds, owner and recovery for users already updated.
+```
+
+## Read-only boundary
+
+A readiness audit inspects files, existing artifacts/logs and accessible CI/store records. Do not build, run tests, install dependencies, execute Fastlane lanes, prebuild, bump versions, tag, upload, change signing or store settings by default. Inspect scripts before considering execution. Prepare exact commands for missing checks and label them **not executed**. An explicit request to execute a release authorizes only that requested scope; reuse existing authorization, and complete reviewable preparation before any additional approval that is actually needed. Never change an app merely to make the audit green.

package/skills/mobile-release/scripts/verdict.mjs

@@ -0,0 +1,59 @@
+import { realpathSync } from 'node:fs';
+import { pathToFileURL } from 'node:url';
+
+const REQUIRED_GATES = ['identity', 'build', 'tests', 'analysis', 'version', 'signing', 'symbols', 'store', 'privacy', 'listing', 'rollout'];
+const text = (value) => typeof value === 'string' && value.trim().length > 0;
+
+/** Validate decision consistency. Evidence truth and applicability remain the auditor's job. */
+export function evaluateReadiness(report) {
+  if (!report || !Array.isArray(report.targets)) throw new Error('targets must be an array');
+  const risks = report.risks ?? [];
+  if (!Array.isArray(risks) || !risks.every((risk) => risk && text(risk.id) && text(risk.description)
+    && Array.isArray(risk.evidence) && risk.evidence.length > 0 && risk.evidence.every(text)
+    && text(risk.mitigation) && text(risk.owner))) {
+    throw new Error('risks must include id, description, evidence, mitigation and owner');
+  }
+  const targets = new Set();
+  const gates = [];
+  for (const item of report.targets) {
+    if (!item || !text(item.target) || !Array.isArray(item.gates)) throw new Error('each target needs a name and gates array');
+    if (targets.has(item.target)) throw new Error(`duplicate target: ${item.target}`);
+    targets.add(item.target);
+    const byId = new Map();
+    for (const gate of item.gates) {
+      if (!gate || !REQUIRED_GATES.includes(gate.id)) throw new Error('unknown gate id');
+      if (byId.has(gate.id)) throw new Error(`duplicate gate: ${gate.id}`);
+      if (!['pass', 'fail', 'unknown'].includes(gate.status)) throw new Error(`invalid status for ${gate.id}`);
+      if (gate.evidence !== undefined && (!Array.isArray(gate.evidence) || !gate.evidence.every((value) => typeof value === 'string'))) {
+        throw new Error(`evidence for ${gate.id} must be a string array`);
+      }
+      byId.set(gate.id, gate);
+    }
+    for (const id of REQUIRED_GATES) {
+      const supplied = byId.get(id);
+      const evidence = (supplied?.evidence ?? []).filter(text);
+      const status = !supplied || (supplied.status !== 'unknown' && !evidence.length) ? 'unknown' : supplied.status;
+      gates.push({
+        target: item.target, id, status, evidence,
+        nextAction: status === 'pass' ? 'None.' : (text(supplied?.nextAction) && supplied.nextAction !== 'None.'
+          ? supplied.nextAction : `Provide and verify ${id} evidence for ${item.target}.`),
+      });
+    }
+  }
+  if (!targets.size) gates.push({ target: 'unresolved', id: 'targets', status: 'unknown', evidence: [], nextAction: 'Identify the app artifacts and intended store targets.' });
+  const blockers = gates.filter((gate) => gate.status !== 'pass');
+  const unknowns = gates.filter((gate) => gate.status === 'unknown');
+  return { verdict: blockers.length ? 'NO-GO' : risks.length ? 'GO WITH RISKS' : 'GO', gates, blockers, risks, unknowns };
+}
+
+// stdin avoids creating an audit file in the inspected project. Exit zero means evaluated, not GO.
+if (process.argv[1] && import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href) {
+  try {
+    let input = '';
+    for await (const chunk of process.stdin) input += chunk;
+    console.log(JSON.stringify(evaluateReadiness(JSON.parse(input)), null, 2));
+  } catch (error) {
+    console.error(`readiness: ${error.message}`);
+    process.exitCode = 1;
+  }
+}

package/skills/mobile-security/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mobile-security
-description: Security review and hardening for mobile apps on every stack, organized by the OWASP MASVS categories — insecure token and credential storage, hardcoded secrets, cleartext traffic and TLS validation bypass, certificate pinning, exported components and intent handling, deep links, WebView bridges, biometrics, sensitive logging, backups, screenshots and release hardening — with concrete checks for Flutter, native Android, native iOS and React Native. Use when reviewing mobile code for security, auditing an app before release, storing tokens or credentials, handling authentication, deep links or WebViews, or when the user mentions OWASP, MASVS, pentest findings or store security requirements.
+description: Reviews mobile security across Flutter, native Android, native iOS, React Native and Kotlin Multiplatform using OWASP MASVS. Covers credential storage, secrets, transport, deep links, WebViews, logging and platform implementations of shared KMP contracts. Use for security audits, auth/token handling, pentest findings or release hardening.
 intents: [review, security, release]
 stacks: ["*"]
 ---
@@ -17,6 +17,7 @@ Organized by the OWASP MASVS categories. Apply the general checks below, then th
 | Native Android (Kotlin/Java), or `android/` in any app | [references/android.md](references/android.md) |
 | Native iOS (Swift/Objective-C), or `ios/` in any app | [references/ios.md](references/ios.md) |
 | React Native or Expo | [references/react-native.md](references/react-native.md) |
+| Kotlin Multiplatform shared code and platform implementations | [references/kotlin-multiplatform.md](references/kotlin-multiplatform.md) |
 
 Firebase-specific protection (security rules, App Check) is covered by `mobile-firebase`.