reis-mobile 0.7.1 → 0.7.2

package/.claude-plugin/marketplace.json

@@ -5,14 +5,14 @@
   },
   "metadata": {
     "description": "AI agents for mobile engineering",
-    "version": "0.7.1"
+    "version": "0.7.2"
   },
   "plugins": [
     {
       "name": "reis-mobile",
       "source": "./",
       "description": "AI agents, skills and workflows for Flutter, Android, iOS and React Native development.",
-      "version": "0.7.1",
+      "version": "0.7.2",
       "author": {
         "name": "Warleson Reis"
       },

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "reis-mobile",
-  "version": "0.7.1",
+  "version": "0.7.2",
   "description": "AI agents, skills and workflows for Flutter, Android, iOS and React Native development. Use /reis-mobile:doctor, /reis-mobile:review and /reis-mobile:test.",
   "author": {
     "name": "Warleson Reis"

package/CHANGELOG.md

@@ -4,6 +4,21 @@ Format based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). The pr
 
 ## [Unreleased]
 
+## [0.7.2] - 2026-09-18
+
+### Added
+
+- Kotlin Multiplatform architect, test and performance specialists, a `mobile-kmp` platform skill and focused KMP references in the eight cross-stack topic skills. Routing and coverage tests guard the new paths.
+- `/reis-mobile:project [feature]` creates or refreshes a verified app object map in `.reis-mobile/project.md` while preserving team-authored product context.
+
+### Changed
+
+- Specialist guidance distinguishes configured shared source sets, Android/iOS host behavior and target-specific validation; the shared brief verifies profile paths and separates team knowledge from code evidence.
+
+### Fixed
+
+- Release automation opens a pull request for synchronized files instead of pushing directly to a protected `main` branch, and waits for those changes to merge before tagging and publishing.
+
 ## [0.7.1] - 2026-09-17
 
 ### Added

package/README.md

@@ -1,8 +1,8 @@
 # 📱 reis-mobile
 
-A mobile app is not a generic project. A code review that does not know about `BuildContext` after `await`, `android:exported`, `NSAllowsArbitraryLoads` or `Podfile.lock` lets through exactly the bugs that only show up on the device. **reis-mobile** detects your project's stack, picks the right specialist and loads only the skills that apply to Flutter, Android, iOS or React Native.
+A mobile app is not a generic project. A code review that does not know about `BuildContext` after `await`, `android:exported`, `NSAllowsArbitraryLoads` or `Podfile.lock` lets through exactly the bugs that only show up on the device. **reis-mobile** detects your project's stack, picks the right specialist and loads only the skills that apply to Flutter, Android, iOS, React Native or Kotlin Multiplatform.
 
-**AI agents and skills for mobile development — Flutter, Android, iOS and React Native.** A plugin for Claude Code and Codex with specialist agents and skills for code review, debugging, tests, architecture, security and Firebase.
+**AI agents and skills for mobile development — Flutter, Android, iOS, React Native and Kotlin Multiplatform.** A plugin for Claude Code and Codex with specialist agents and skills for code review, debugging, tests, architecture, security and Firebase.
 
 <p align="center">
   <a href="https://github.com/wrsilva/reis-mobile/actions/workflows/ci.yml"><img src="https://github.com/wrsilva/reis-mobile/actions/workflows/ci.yml/badge.svg" alt="CI"></a>
@@ -23,7 +23,9 @@ A mobile app is not a generic project. A code review that does not know about `B
 
 🔎 **Detects the stack on its own.** Flutter (app or plugin), React Native (including Expo), Kotlin Multiplatform, native Android and iOS, with languages and target platforms. A Flutter app with `android/` and `ios/` is still Flutter.
 
-👥 **18 agents and 13 mobile skills.** Architect, performance and test engineers for Flutter, native Android, native iOS and React Native, a staff engineer, a native plugin specialist, a code reviewer, an accessibility auditor, a release engineer and a lead that coordinates them all, plus skills for Gradle, Xcode and CocoaPods builds, Jetpack Compose, BLoC, Riverpod, Firebase and testing on every platform, plugins, security, accessibility and releases.
+👥 **21 agents and 14 mobile skills.** Architect, performance and test engineers for Flutter, native Android, native iOS, React Native and Kotlin Multiplatform, plus a staff engineer, a native plugin specialist, a code reviewer, an accessibility auditor, a release engineer and a lead. Topic skills cover the five stacks with focused references for debugging, tests, security, Firebase, accessibility and releases.
+
+🧩 **Project-specific context.** `/reis-mobile:project` records real app symbols, owners, boundaries and validation commands in `.reis-mobile/project.md`; the team can add product rules that code cannot reveal. Refreshing the verified map preserves team-authored text.
 
 🌐 **Answers in English or Portuguese.** `reis-mobile init eng` or `reis-mobile init pt` sets the language of reports, explanations and debates.
 
@@ -42,17 +44,20 @@ A mobile app is not a generic project. A code review that does not know about `B
 ## What's new
 
 <!-- reis-mobile:latest-release:start -->
-### v0.7.1
+### v0.7.2
 
 #### Added
 
-- A `SessionStart` hook for Claude Code and Codex that warns when the installed plugin is behind npm's latest release. It caches registry results for 24 hours, stays silent offline and can be disabled with `REIS_MOBILE_UPDATE_CHECK=0`.
-- `reis-mobile update-check [--force]` for manually checking the CLI version.
+- Kotlin Multiplatform architect, test and performance specialists, a `mobile-kmp` platform skill and focused KMP references in the eight cross-stack topic skills. Routing and coverage tests guard the new paths.
+- `/reis-mobile:project [feature]` creates or refreshes a verified app object map in `.reis-mobile/project.md` while preserving team-authored product context.
 
 #### Changed
 
-- `package.json` is the only editable version source. CI synchronizes the plugin manifests and the Release workflow tests, tags and publishes a new version after it reaches `main`.
-- Version synchronization now promotes authored `[Unreleased]` notes to a dated changelog section and refreshes the README's latest-release summary without changing historical entries.
+- Specialist guidance distinguishes configured shared source sets, Android/iOS host behavior and target-specific validation; the shared brief verifies profile paths and separates team knowledge from code evidence.
+
+#### Fixed
+
+- Release automation opens a pull request for synchronized files instead of pushing directly to a protected `main` branch, and waits for those changes to merge before tagging and publishing.
 
 <!-- reis-mobile:latest-release:end -->
 
@@ -225,10 +230,11 @@ After editing agents, skills or commands, restart Claude Code or Codex.
 ## Commands
 
 ```bash
-/reis-mobile                                      # Lists the commands (also accepts doctor, review, debug, test, debate or a free-form request)
+/reis-mobile                                      # Lists the commands (also accepts doctor, project, review, debug, test, debate or a free-form request)
 /reis-mobile my android build fails on gradle     # Free-form request: detects the stack and applies the right agent and skills
 /reis-mobile:doctor                               # Environment and project: SDKs, Xcode, CocoaPods, Gradle wrapper, lock files
 /reis-mobile:doctor --all                         # Checks every tool, not only those for the detected stack
+/reis-mobile:project checkout                     # Records actual checkout objects and test commands in .reis-mobile/project.md
 /reis-mobile:review                               # Reviews uncommitted changes (or the whole project, if there are none)
 /reis-mobile:review --base main                   # Reviews the current branch against main, pull request style
 /reis-mobile:review --base main focus on security # Free-form focus, in English or Portuguese
@@ -261,6 +267,10 @@ reis-mobile test --base main -- "write regression tests for these changes"
 
 Its output includes the resolved project directory, explicit `test` intent, selected specialist and skills, redacted change context, toolchain diagnostics and answer language. `/reis-mobile test ...` forwards to the same slash-command workflow.
 
+### Project context
+
+`/reis-mobile:project [feature]` resolves the mobile app, traces real entry points, state owners, data or native boundaries and nearby tests, then creates or refreshes `.reis-mobile/project.md`. In a monorepo it writes beside `.reis-mobile/config.yaml`; otherwise it writes in the app root. The generated section contains only facts tied to code or configuration and identifies unknown product rules. Team-authored sections remain intact on refresh. Agents check its paths and commands against the current checkout before using them.
+
 ### Debate
 
 `/reis-mobile:debate` puts three specialists with conflicting priorities to defend positions on the same question. Round 1 is blind, so the first to answer does not anchor the others; in round 2 each one rebuts specific points from the others; at the end, `lead-mobile` decides and delivers the action plan. The rounds are stored in `.reis-mobile/debates/`.
@@ -299,9 +309,10 @@ The router never invents a specialist: if no agent serves the intent, it warns y
 | Review a PR or my changes | `/reis-mobile:review` | ✅ |
 | Audit an entire Flutter project | `/reis-mobile:review` with no pending changes | ✅ |
 | Find out a project's stack | `reis-mobile detect` | ✅ |
-| Review the architecture of an app | agent `flutter-architect`, `android-architect`, `ios-architect` or `rn-architect` | ✅ |
-| Find the cause of jank, rebuilds, hangs or leaks | agent `flutter-`, `android-`, `ios-` or `rn-performance-engineer` | ✅ |
-| Write or audit tests | agent `flutter-`, `android-`, `ios-` or `rn-test-engineer` | ✅ |
+| Record the app's real objects and team context | `/reis-mobile:project [feature]` | ✅ |
+| Review the architecture of an app | agent `flutter-architect`, `android-architect`, `ios-architect`, `rn-architect` or `kmp-architect` | ✅ |
+| Find the cause of jank, rebuilds, hangs or leaks | stack-specific `*-performance-engineer` | ✅ |
+| Write or audit tests | stack-specific `*-test-engineer` | ✅ |
 | Debug a Gradle, Xcode, CocoaPods or Flutter build | `/reis-mobile:debug` | ✅ |
 | Build a plugin or debug MethodChannel/EventChannel | agent `plugin-native-expert` | ✅ |
 | Audit a screen for TalkBack, VoiceOver, touch targets and text scaling | agent `mobile-accessibility-auditor` | ✅ |
@@ -321,7 +332,7 @@ The router never invents a specialist: if no agent serves the intent, it warns y
 | **Project context** | You explain the stack | Deterministic detection of stack, platform and variant |
 | **Review** | Generic | Mobile checklists: lifecycle, `BuildContext`, MASVS, manifest, ATS |
 | **Secrets in the diff** | Sent as they are | Masked before reaching the model |
-| **Specialists** | None | 18 agents and 13 mobile skills |
+| **Specialists** | None | 21 agents and 14 mobile skills |
 | **Context cost** | Zero | ~4,300 fixed tokens (agent and skill descriptions), no hooks |
 | **Best for** | General tasks | Teams and developers working on mobile apps |
 
@@ -377,13 +388,16 @@ For domain knowledge that code cannot reveal, optionally commit `.reis-mobile/pr
 | `rn-architect` | React Native | architecture | Feature structure, server vs client state, navigation, native modules |
 | `rn-performance-engineer` | React Native | performance | Re-renders, lists, JavaScript thread, animations, startup, bundle size |
 | `rn-test-engineer` | React Native | test | Jest, React Native Testing Library, native module mocks, Detox or Maestro |
+| `kmp-architect` | Kotlin Multiplatform | architecture | Shared source-set ownership, Android/iOS callers and Swift-facing contracts |
+| `kmp-performance-engineer` | Kotlin Multiplatform | performance | Shared Kotlin cost versus Android/iOS host traces and bridge overhead |
+| `kmp-test-engineer` | Kotlin Multiplatform | test | `commonTest`, target tests and Android/iOS host coverage |
 | `mobile-accessibility-auditor` | all | accessibility | Screen reader labels, roles and states, touch targets, text scaling, focus and announcements, with fixes per platform |
 | `mobile-release-engineer` | all | release, deployment | Go/no-go readiness, versions and signing, crash symbols, release notes and store copy, CI/CD, staged rollout |
-| `mobile-staff-engineer` | all | debug, architecture, performance, test, security, migration, dependency, build | Senior Flutter/Android/iOS specialist for whatever no specific agent covers |
+| `mobile-staff-engineer` | all | debug, architecture, performance, test, security, migration, dependency, build | Cross-toolchain diagnosis and migrations when no stack specialist owns the intent |
 | `plugin-native-expert` | Flutter | on demand | MethodChannel, EventChannel, Pigeon and Kotlin/Swift bridges, threading and lifecycle |
 | `lead-mobile` | all | on demand | Coordinates the other agents and consolidates a single action plan |
 
-When more than one agent serves the intent, the stack-specific one wins. In a Flutter app, `performance` goes to `flutter-performance-engineer`; in a native Android app, to `android-performance-engineer`. `accessibility` goes to `mobile-accessibility-auditor` and `release` or `deployment` to `mobile-release-engineer` on every stack. Other intents without a stack specialist, such as `debug`, go to `mobile-staff-engineer`.
+When more than one agent serves the intent, the stack-specific one wins. In a Flutter app, `performance` goes to `flutter-performance-engineer`; in a KMP app, to `kmp-performance-engineer`. `accessibility` goes to `mobile-accessibility-auditor` and `release` or `deployment` to `mobile-release-engineer` on every stack. Other intents without a stack specialist, such as `debug`, go to `mobile-staff-engineer`.
 
 ### Skills
 
@@ -391,18 +405,19 @@ Every skill starts with `mobile-`. **Topic** skills cover every stack with one r
 
 | Skill | Covers | Auto-routed for | References |
 |---|---|---|---|
-| `mobile-architecture` | Layers, state management, modularization, DI, navigation | architecture | Flutter (BLoC, Riverpod, Provider, ChangeNotifier...), Android, iOS, React Native |
-| `mobile-code-review` | Review process and checklists | review, performance | Flutter (PR review, widgets, project audit, static analysis), Android, iOS, React Native |
-| `mobile-debug` | Failing builds and runtime errors | debug, build, dependency, migration | Flutter (build, runtime, layout, packages), Android (Gradle, crashes, ANRs, memory leaks), iOS (Xcode, CocoaPods, crash logs), React Native (Metro, native modules), deep links |
-| `mobile-test` | Unit, UI, integration and end-to-end tests | test | Flutter (widget, integration, Patrol, mocks, coverage), Android, iOS, React Native |
-| `mobile-security` | OWASP MASVS security checks | review, security, release | Flutter (token storage), Android (intents), iOS, React Native |
-| `mobile-accessibility` | Screen readers, touch targets, text scaling, contrast | accessibility | Flutter (Semantics), Android (Compose and Views), iOS (SwiftUI and UIKit), React Native |
-| `mobile-release` | Release readiness, store copy and CI/CD | release, deployment | Flutter, Android, iOS, React Native, release notes and store listing, CI/CD |
-| `mobile-firebase` | Firebase setup and 13 products | — | Flutter, Android, iOS, React Native, each with a guide per product |
+| `mobile-architecture` | Layers, state management, modularization, DI, navigation | architecture | Flutter (BLoC, Riverpod, Provider, ChangeNotifier...), Android, iOS, React Native, KMP |
+| `mobile-code-review` | Review process and checklists | review, performance | Flutter (PR review, widgets, project audit, static analysis), Android, iOS, React Native, KMP |
+| `mobile-debug` | Failing builds and runtime errors | debug, build, dependency, migration | Flutter (build, runtime, layout, packages), Android (Gradle, crashes, ANRs, memory leaks), iOS (Xcode, CocoaPods, crash logs), React Native (Metro, native modules), KMP, deep links |
+| `mobile-test` | Unit, UI, integration and end-to-end tests | test | Flutter (widget, integration, Patrol, mocks, coverage), Android, iOS, React Native, KMP |
+| `mobile-security` | OWASP MASVS security checks | review, security, release | Flutter (token storage), Android (intents), iOS, React Native, KMP |
+| `mobile-accessibility` | Screen readers, touch targets, text scaling, contrast | accessibility | Flutter (Semantics), Android (Compose and Views), iOS (SwiftUI and UIKit), React Native, KMP |
+| `mobile-release` | Release readiness, store copy and CI/CD | release, deployment | Flutter, Android, iOS, React Native, KMP, release notes and store listing, CI/CD |
+| `mobile-firebase` | Firebase setup and 13 products | — | Flutter, Android, iOS, React Native, KMP; check installed SDK support |
 | `mobile-flutter` | Flutter and Dart specifics | review, performance, accessibility, migration | UI and navigation, data, native code, performance, accessibility and i18n, Dart, setup |
 | `mobile-android` | Native Android specifics, from the Android team | performance, release, migration, build, dependency | Compose UI, AGP 9 and R8, profiling, Google Play, identity, camera and media, on-device AI, Wear OS, TV, XR |
 | `mobile-ios` | Native iOS specifics | performance, release, accessibility | UI and navigation, data and networking, platform features, performance and release |
 | `mobile-rn` | React Native and Expo specifics | performance, release, accessibility | UI and navigation, data and networking, platform features, performance and release |
+| `mobile-kmp` | Kotlin Multiplatform shared and target boundaries | architecture, test, performance, review, debug and more | Source sets, Apple interop, shared Compose UI, build and profiling |
 | `mobile-detect-stack` | Deterministic stack detection with the CLI | — | — |
 
 Skills marked — are triggered by Claude Code when the request matches their description, for example *"add push notifications with FCM"* → `mobile-firebase`.
@@ -413,7 +428,7 @@ About 85 guides come from [flutter/skills](https://github.com/flutter/skills), [
 
 ## Trust, security and limits
 
-**Read-only CLI context.** `doctor`, `detect`, `route`, `review` and `test` do not modify your project. The `/reis-mobile:test` slash command can write or fix tests and execute runners when requested. The `/reis-mobile:review` and `/reis-mobile:debate` commands instruct the model not to edit files; the debate only writes its rounds to `.reis-mobile/debates/`, outside your code.
+**Read-only CLI context.** `doctor`, `detect`, `route`, `review` and `test` do not modify your project. The `/reis-mobile:test` slash command can write or fix tests and execute runners when requested. `/reis-mobile:project` writes only the optional project profile. The `/reis-mobile:review` and `/reis-mobile:debate` commands instruct the model not to edit app code; the debate writes its rounds to `.reis-mobile/debates/`.
 
 **Secrets masked.** The diff goes through [`core/security/redact.mjs`](core/security/redact.mjs) before reaching the model. Lock files and generated code (`*.g.dart`, `*.freezed.dart`, `*.pbxproj`) stay out of the diff. Redaction is a protection layer, not a guarantee. See [SECURITY.md](SECURITY.md).
 
@@ -421,7 +436,7 @@ About 85 guides come from [flutter/skills](https://github.com/flutter/skills), [
 
 **Exception: `/reis-mobile:debate --external`.** This flag, and only this flag, sends the debate context — including excerpts of the files mentioned in the question — to the `codex` and `gemini` CLIs, which are third-party and have their own data policies. Without the flag, the debate context stays in your session. The `review` diff is masked by `redact.mjs`, but the context you cite in a debate question does not go through that layer: check what you are sending before using `--external`.
 
-**Context cost.** The descriptions of the 18 agents and 13 skills add up to about 4,300 fixed tokens per session, estimated from their length (v0.3 measured about 4,800 with `claude plugin details reis-mobile`). The full content of each skill is only loaded when it is used.
+**Context cost.** Claude Code loads the descriptions of 21 agents and 14 skills; the full content of each skill is loaded only when it is used. The exact description cost depends on the host and plugin version.
 
 **One session hook.** On session startup or resume, the plugin checks for a newer release and warns only when the installed plugin is outdated. It does not read the project or modify the plugin installation.
 

package/agents/kmp-architect.md

@@ -0,0 +1,26 @@
+---
+name: kmp-architect
+description: Use this agent to design or review Kotlin Multiplatform architecture across `commonMain`, Android/iOS source sets and host apps. It traces real shared domain types, `expect`/`actual` or injected interfaces, framework exports and state ownership before choosing what to share. Typical triggers are moving a feature into a shared module, untangling `iosMain`/`androidMain`, and deciding whether UI or only logic should be shared.
+model: inherit
+color: cyan
+tools: ["Read", "Grep", "Glob"]
+intents: [architecture]
+stacks: [kotlin-multiplatform]
+---
+
+You own the shared-versus-target boundary, not an Android module diagram with an iOS folder appended. Produce a read-only design based on the targets and symbols this project actually builds.
+
+Read the [project brief](../docs/agent-context.md) once or reuse the caller's verified brief. Apply [mobile-kmp](../skills/mobile-kmp/SKILL.md), its [source-set guide](../skills/mobile-kmp/references/source-sets.md) and [mobile-architecture](../skills/mobile-architecture/SKILL.md) with the [KMP architecture reference](../skills/mobile-architecture/references/kotlin-multiplatform.md).
+
+## Trace the contract
+
+1. Map included Gradle modules, configured targets, source-set `dependsOn` edges and iOS framework/host integration. Mark generated artifacts separately from editable source.
+2. Follow one requested action from the Android and iOS entry points to the same shared Kotlin type. Name the state owner, repository/service interface, platform implementation and where each error returns to UI. If the UIs are separate, document their adapters instead of assuming shared Compose.
+3. Inventory the actual feature objects: identifiers, domain values, DTOs, persisted models and Swift-facing types. Show conversion and validation at each boundary; identify which object is authoritative and who can write it.
+4. Compare `expect`/`actual` and injected interfaces against the size of the platform behavior and the project's existing pattern. Check target completeness and the ownership of coroutine scopes, callbacks and native resources.
+
+## Decide and hand off
+
+Choose the smallest boundary that removes a demonstrated duplication or coupling problem. Specify the shared API, target implementations, error/nullability contract, construction site and migration seam; name new symbols as proposed. Avoid a framework migration or shared UI proposal without evidence from both host apps.
+
+Return a table of **object → source set → owner/lifetime → Android caller → iOS caller → test seam**, plus the current source-set graph and a stepwise design with actual paths. Include the target builds and tests that would prove each contract. A Kotlin compilation alone does not prove the Swift consumer works.

package/agents/kmp-performance-engineer.md

@@ -0,0 +1,24 @@
+---
+name: kmp-performance-engineer
+description: Use this agent to diagnose Kotlin Multiplatform performance across shared Kotlin work, Compose Multiplatform and Android/iOS hosts. It separates shared algorithm or serialization cost from Android frame/ANR evidence, iOS hangs and framework-bridge overhead. Typical triggers are a shared repository making both apps slow, iOS-only jank after a KMP change, startup delay from framework initialization, and retained objects across a Swift/Kotlin boundary.
+model: inherit
+color: yellow
+tools: ["Read", "Grep", "Glob", "Bash"]
+intents: [performance]
+stacks: [kotlin-multiplatform]
+---
+
+You isolate one measured KMP regression and its target-specific consequence. Return a falsifiable cause and a bounded fix proposal, not a generic performance checklist.
+
+Read or reuse the [project brief](../docs/agent-context.md). Apply [mobile-kmp](../skills/mobile-kmp/SKILL.md), its [build/performance guide](../skills/mobile-kmp/references/build-performance.md), and the [KMP review reference](../skills/mobile-code-review/references/kotlin-multiplatform.md).
+
+## Split the cost by boundary
+
+1. Fix the app revision, module, affected Android/iOS target, build configuration, device and user journey. Trace the initiating UI action through the shared Kotlin symbol, platform implementation, native framework/API and visible result.
+2. For shared code, inspect the exact algorithm, allocation, serialization or cache path and its input volume. Compare outputs and work performed on both targets before calling it a common-code regression.
+3. For Android, use the app's frame/ANR/heap evidence and name the Kotlin call on the blocked path. For iOS, use a symbolicated hang/Time Profiler or memory trace and the exported framework boundary. If UI is shared, distinguish Compose state invalidation from Kotlin data work and host rendering.
+4. For retained memory or startup, find the creator and owner of the shared object, coroutine/task and Swift callback. Show the retaining or blocking chain; do not recommend weak references, dispatchers or memoization without that chain.
+
+## Measurement artifact
+
+State whether the evidence came from Android, iOS or both. Provide **journey → trace interval → source symbol → cost owner → proposed change → correctness risk → comparable before/after metric**. Use the same input and release-like conditions for comparisons. If no profiler run was possible, label the finding a static hypothesis and provide the exact capture needed; never transfer a JVM timing result to iOS.

package/agents/kmp-test-engineer.md

@@ -0,0 +1,26 @@
+---
+name: kmp-test-engineer
+description: Use this agent to write, fix or audit Kotlin Multiplatform tests in `commonTest` and configured target test source sets, including `expect`/`actual` behavior, Kotlin/Native iOS test binaries, Android host tests and Compose Multiplatform UI. Typical triggers are testing shared business logic, a bug that appears only on iOS, flaky target-specific tests, or a KMP project where Android tests pass but iOS behavior is unknown.
+model: inherit
+color: green
+tools: ["Read", "Grep", "Glob", "Bash", "Edit", "Write"]
+intents: [test]
+stacks: [kotlin-multiplatform]
+---
+
+You own the test matrix across shared logic, target implementations and host apps. An audit request stays read-only; a request to add or fix tests authorizes the relevant files.
+
+Reuse the [project brief](../docs/agent-context.md) or read it once. Load [mobile-kmp](../skills/mobile-kmp/SKILL.md), [mobile-test](../skills/mobile-test/SKILL.md) and the [KMP testing reference](../skills/mobile-test/references/kotlin-multiplatform.md).
+
+## Choose the test target
+
+1. Read the affected module's targets, source sets, test dependencies and Gradle tasks. Locate the real Kotlin symbol, `actual` implementations, nearest tests and any Android/iOS app test targets. Do not assume a `commonTest` case runs on every declared target in CI.
+2. Put shared rules and serialization cases in the source set that owns them. For platform behavior, test the Android and iOS implementation with the relevant target runner and controlled external boundary. Name the observable result, not just a mock invocation.
+3. For `expect`/`actual`, include a contract case that both implementations can satisfy, then target-specific cases for permissions, storage, threading or interop that differ. Verify the test source set is connected to each target and the task discovers a nonzero test count.
+4. For Compose Multiplatform, use the test API supported by the installed version and prove the interaction on relevant targets. A common UI test does not replace Android instrumentation or XCUITest when the behavior crosses a host, system dialog or native SDK.
+
+## Execute and report
+
+Discover exact tasks with the Gradle wrapper instead of guessing target names. Run the narrow shared and target suites available here; iOS tests need a compatible macOS/Xcode environment. Keep fixture data, schedulers and native stores isolated; avoid arbitrary sleeps.
+
+Return a matrix of **production symbol → source set/target → test file → scenario/assertion → task → executed count/result**. Separate Android, iOS and host UI coverage. If one target cannot run, mark it unrun with the concrete prerequisite; a green JVM task is not a KMP-wide pass.

package/agents/lead-mobile.md

@@ -30,6 +30,9 @@ Agents use the `reis-mobile:` prefix in the Agent tool. Choose by stack and deli
 | Route, cache/client-state and native-module boundaries | `reis-mobile:rn-architect` |
 | React render, JavaScript and native-thread costs | `reis-mobile:rn-performance-engineer` |
 | Jest/component tests and configured device journeys | `reis-mobile:rn-test-engineer` |
+| KMP source-set, shared object and Android/iOS contract design | `reis-mobile:kmp-architect` |
+| KMP common/target tests and host coverage | `reis-mobile:kmp-test-engineer` |
+| Shared Kotlin versus Android/iOS host performance cause | `reis-mobile:kmp-performance-engineer` |
 | Diff regression with concrete trigger and consequence | `reis-mobile:mobile-code-reviewer` |
 | Assistive-technology journey and control semantics | `reis-mobile:mobile-accessibility-auditor` |
 | Release identity, artifact gates, notes or pipeline | `reis-mobile:mobile-release-engineer` |

package/commands/debate.md

@@ -48,6 +48,9 @@ Choose **three** agents whose priorities genuinely conflict on the question. A d
 | `reis-mobile:rn-architect` | Feature boundaries, server vs client state, native module isolation | `opus` |
 | `reis-mobile:rn-performance-engineer` | Re-renders, lists, JavaScript thread, startup | `sonnet` |
 | `reis-mobile:rn-test-engineer` | Testability through the UI, mocks at boundaries, coverage cost | `sonnet` |
+| `reis-mobile:kmp-architect` | Shared source-set ownership, host API contracts and migration cost | `opus` |
+| `reis-mobile:kmp-performance-engineer` | Shared Kotlin cost versus Android/iOS host traces and bridge overhead | `sonnet` |
+| `reis-mobile:kmp-test-engineer` | Common and target tests, host integration and coverage gaps | `sonnet` |
 | `reis-mobile:plugin-native-expert` | Flutter–native boundary, platform channels, lifecycle | `opus` |
 | `reis-mobile:mobile-staff-engineer` | Build, release, migration, cross-platform trade-offs | `opus` |
 | `reis-mobile:mobile-code-reviewer` | Concrete risk in the code that already exists | `sonnet` |
@@ -58,7 +61,7 @@ Automatic selection must end with **at least two different models** among the pa
 
 Selection rules:
 
-- The detected stack rules. The `flutter-*` agents only join Flutter projects, `android-*` native Android, `ios-*` native iOS and `rn-*` React Native. Pick the architect, performance and test specialists of the detected stack first; `mobile-staff-engineer` and `mobile-code-reviewer` fit any stack.
+- The detected stack rules. The `flutter-*` agents only join Flutter projects, `android-*` native Android, `ios-*` native iOS, `rn-*` React Native and `kmp-*` Kotlin Multiplatform. Pick the architect, performance and test specialists of the detected stack first; `mobile-staff-engineer` and `mobile-code-reviewer` fit any stack.
 - Without native code in the project, do not call `plugin-native-expert`.
 - `--agents` overrides the automatic choice, but not the models: each agent keeps the one from the table. Unknown name: warn and stop.
 - `reis-mobile:lead-mobile` never debates — it moderates in step 7, always on `opus`, because synthesizing conflicting positions is the heaviest work in the flow.

package/commands/project.md

@@ -0,0 +1,48 @@
+---
+description: Build or refresh a project-specific mobile brief from actual app objects, boundaries and validation commands
+argument-hint: "[feature or flow to prioritize]"
+allowed-tools: ["Bash(node:*)", "Bash(git:*)", "Read", "Grep", "Glob", "Edit", "Write"]
+---
+
+# reis-mobile project
+
+Arguments received: `$ARGUMENTS`
+
+## Resolve the mobile app and profile
+
+Run `node "${CLAUDE_PLUGIN_ROOT}/bin/reis-mobile.mjs" detect --json --dir "$PWD"`. Parse the JSON result; use `projectDir` as the app root. If `projectConfig` is present, place the profile at `.reis-mobile/project.md` beside that config file. Otherwise place it at `<projectDir>/.reis-mobile/project.md`. Do not write a profile for an unknown stack or a missing project root. Read `${CLAUDE_PLUGIN_ROOT}/docs/agent-context.md` before collecting evidence.
+
+The optional arguments identify a feature or flow to prioritize, not a shell command. Never evaluate them as shell code. Resolve source paths against the app root, and paths in a monorepo-wide CI file against the repository root.
+
+## Collect project evidence
+
+Inspect applicable repository instructions, architecture docs, build manifests, lock files, source entry points, navigation, dependency wiring, two or three representative features and their nearest tests. For the requested feature, inspect its actual user action, state owner, repository/service, data model, external or native boundary, and failure path. For an unscoped run, select one critical journey only when code or team documentation identifies it; otherwise record a representative implemented flow and label it as such.
+
+Use the detected stack and configured targets. For Kotlin Multiplatform, map `commonMain`, target source sets and Android/iOS host callers. Read the real CI jobs, package scripts, Gradle tasks or Xcode schemes before listing validation commands. Never invent a domain object, test target, supported OS, business invariant or command from a skill example. Mark facts without evidence as unknown and state what could establish them.
+
+## Write or refresh the brief
+
+Create the profile if absent. On refresh, replace only the content between these exact markers:
+
+```markdown
+<!-- reis-mobile:verified:start -->
+## Verified code map
+...
+<!-- reis-mobile:verified:end -->
+```
+
+If an existing profile lacks the markers, preserve all existing text and append the marked block. Do not rewrite or remove team-authored sections, even when they conflict with code; identify the discrepancy after the block. Never copy secrets, credentials, tokens, personal data or raw environment values into the profile.
+
+The verified block contains:
+
+1. App root, detected stack/targets and the manifest or configuration paths that prove them.
+2. A compact table of **real object/symbol → path → owner/lifetime → caller or event → next boundary → nearest test**. Mark an absent test as `none found`, not as a claim that no tests exist.
+3. One concrete flow from entry action through state and data/native boundary to observable result, with paths and symbols.
+4. Existing validation commands with working directory and their source (CI/script/task/scheme). Distinguish commands inspected from commands actually run.
+5. Unknowns and stale references that require team confirmation.
+
+For a new profile, add a short `## Team context` section after the verified block with prompts for product vocabulary, critical journeys, business invariants, supported environments and deliberate exceptions. Leave values as `Unknown — team input needed` until the team supplies them. Do not fabricate a product description.
+
+## Report
+
+State the profile path, the flow and objects recorded, evidence that was verified, commands actually run and the remaining unknowns. Follow the CLI's `language`: `pt` is Brazilian Portuguese; `en` is English; otherwise follow the user's language. Code identifiers, paths and quoted output remain unchanged.

package/commands/reis-mobile.md

@@ -1,7 +1,7 @@
 ---
-description: reis-mobile entry point — lists the commands or forwards to doctor, review, debug, test, debate or the right agent from a free-form request
-argument-hint: "[doctor | review | debug | test | debate | free-form request]"
-allowed-tools: ["Bash(node:*)", "Bash(git:*)", "Read", "Grep", "Glob"]
+description: reis-mobile entry point — lists the commands or forwards to doctor, project, review, debug, test, debate or the right agent from a free-form request
+argument-hint: "[doctor | project | review | debug | test | debate | free-form request]"
+allowed-tools: ["Bash(node:*)", "Bash(git:*)", "Read", "Grep", "Glob", "Edit", "Write"]
 ---
 
 # reis-mobile
@@ -20,6 +20,7 @@ Reply only with this list. The only thing to run is `node "${CLAUDE_PLUGIN_ROOT}
 
 ```text
 /reis-mobile:doctor                  Environment and project: SDKs, Xcode, CocoaPods, Gradle wrapper, lock files
+/reis-mobile:project [feature]       Creates or refreshes a brief with actual app objects and team context
 /reis-mobile:review [--base <ref>]   Code review of the changes (or the whole project)
 /reis-mobile:debug <problem>         Finds the cause of a build or runtime failure and proposes the fix
 /reis-mobile:test [request]          Runs, writes, audits or fixes tests using the project's test setup
@@ -34,6 +35,10 @@ When the language is `pt`, translate the descriptions and keep the commands as t
 1. Run via Bash: `node "${CLAUDE_PLUGIN_ROOT}/bin/reis-mobile.mjs" doctor --dir "$PWD" <options>`.
 2. Read `${CLAUDE_PLUGIN_ROOT}/commands/doctor.md` and follow its **Instructions** section on that output.
 
+## `project [feature]`
+
+Read `${CLAUDE_PLUGIN_ROOT}/commands/project.md` and follow all of it, treating the rest of the arguments (without the word `project`) as `$ARGUMENTS`. This entry point has the same behavior as `/reis-mobile:project`.
+
 ## `review [options] [focus]`
 
 Read `${CLAUDE_PLUGIN_ROOT}/commands/review.md` and follow all of it, treating the rest of the arguments (without the word `review`) as `$ARGUMENTS`.

package/core/registry/registry.mjs

@@ -17,6 +17,7 @@ export const PLATFORM_SKILLS = {
   'mobile-android': 'android',
   'mobile-ios': 'ios',
   'mobile-rn': 'react-native',
+  'mobile-kmp': 'kotlin-multiplatform',
 };
 
 /**

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.2",
+  "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: ["*"]
 ---
@@ -17,6 +17,7 @@ One release process for every mobile stack. This file holds the process and what
 | 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) |
 

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-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`.
 

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

@@ -0,0 +1,10 @@
+# Kotlin Multiplatform security
+
+Trace a credential or sensitive value through shared code and both host apps. Mark the concrete storage and network implementations used by each target.
+
+- A `commonMain` interface called `SecureStorage` is not proof of protection: inspect Android's Keystore-backed implementation and iOS Keychain implementation, their failure behavior and how logout clears each store. Do not claim an API exists until the dependency and target code confirm it.
+- Check that shared serializers, caches and logs do not persist or emit tokens or personal data in plain text. Identify the exact object, path and caller.
+- Check platform transport configuration in Android and iOS hosts: cleartext allowances, TLS overrides, deep-link handlers and WebView bridges are target-specific.
+- Check that secrets are not embedded in shared resources or framework exports; anything bundled into either app is extractable.
+
+For each finding, give **source path:line → target(s) → exposed object → consequence → fix**. Apply the [Android](android.md) and [iOS](ios.md) references to affected host files, and follow the project's actual storage/network dependencies. The shared source-set boundary is explained in [mobile-kmp](../../mobile-kmp/references/source-sets.md).

package/skills/mobile-test/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mobile-test
-description: Writes, runs and reviews automated tests for mobile apps on every stack — Flutter and Dart (unit, widget and integration tests, Patrol, mocktail, mockito, coverage, package:checks), native Android (JUnit, coroutines and Flow tests, Robolectric, Compose UI tests, Espresso, Hilt, screenshot tests), native iOS (Swift Testing, XCTest, XCUITest) and React Native (Jest, React Native Testing Library, Detox, Maestro). Use whenever the user wants to add, fix or audit tests, set up a test stack, mock dependencies, measure coverage or deal with flaky tests in a mobile project, even if they only name a class to test.
+description: Writes, runs and reviews mobile tests across Flutter, native Android, native iOS, React Native and Kotlin Multiplatform. Covers Dart widget/integration tests, JUnit/Compose/Espresso, XCTest/XCUITest, Jest/Detox, and KMP common/target tests. Use to add, fix, run or audit tests, test setup, mocks, coverage and flaky tests for a real app behavior.
 intents: [test]
 stacks: ["*"]
 ---
@@ -19,6 +19,7 @@ Detect the stack first (the router result, or `pubspec.yaml`, Gradle files, the
 | Native Android (Kotlin), or the Android side of Kotlin Multiplatform | [references/android.md](references/android.md); for setting up a test stack from scratch, [references/android/setup/GUIDE.md](references/android/setup/GUIDE.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 and target tests | [references/kotlin-multiplatform.md](references/kotlin-multiplatform.md) |
 
 A cross-platform app with native code (`android/`, `ios/`, native modules) uses the native reference for that code.
 

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

@@ -0,0 +1,12 @@
+# Kotlin Multiplatform tests
+
+Resolve the configured targets and actual Gradle test tasks before running a command. Use the [KMP testing guide](https://kotlinlang.org/docs/multiplatform-run-tests.html) and the project's Kotlin plugin version to interpret the task graph.
+
+| Behavior under test | Location and runner |
+|---|---|
+| Shared domain rule or mapper | `commonTest`; run the configured target test tasks that compile and execute it. |
+| Android or iOS `actual` implementation | The matching target test source set and runner; a JVM-only pass does not cover Kotlin/Native. |
+| Swift adapter or native host flow | The host app's XCTest/XCUITest or Android local/instrumented suite, depending on the boundary. |
+| Shared Compose screen | Compose Multiplatform UI test where supported by the installed version; also verify the target accessibility and host flow. |
+
+For each requested test, record **source path:symbol → input → result → dependency seam → test source set → real task**. Use existing fixtures and test libraries. Discover task names with the project's Gradle wrapper; avoid assuming all iOS targets run on the current machine. Inspect test counts and target results, not only a successful compilation. [Compose Multiplatform UI testing](https://kotlinlang.org/docs/multiplatform/compose-test.html) has separate host constraints.