reis-mobile 0.7.1 → 0.7.3

package/.claude-plugin/marketplace.json

@@ -5,14 +5,14 @@
   },
   "metadata": {
     "description": "AI agents for mobile engineering",
-    "version": "0.7.1"
+    "version": "0.7.3"
   },
   "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.3",
       "author": {
         "name": "Warleson Reis"
       },

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "reis-mobile",
-  "version": "0.7.1",
+  "version": "0.7.3",
   "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,28 @@ Format based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). The pr
 
 ## [Unreleased]
 
+## [0.7.3] - 2026-09-21
+
+### Added
+
+- `/reis-mobile:release [request]` and entry-command forwarding audit mobile store readiness with per-target identity, pass/fail/unknown evidence gates and GO/GO WITH RISKS/NO-GO verdicts. A packaged helper rejects incomplete evidence; audits remain read-only by default.
+- `reis-mobile release` prepares routing, redacted git context, diagnostics and release references for all five stacks, including both native artifacts in cross-platform apps. A public Flutter sample audit demonstrates the report and external verification limits.
+
+## [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,12 @@ 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.3
 
 #### 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.
-
-#### 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.
+- `/reis-mobile:release [request]` and entry-command forwarding audit mobile store readiness with per-target identity, pass/fail/unknown evidence gates and GO/GO WITH RISKS/NO-GO verdicts. A packaged helper rejects incomplete evidence; audits remain read-only by default.
+- `reis-mobile release` prepares routing, redacted git context, diagnostics and release references for all five stacks, including both native artifacts in cross-platform apps. A public Flutter sample audit demonstrates the report and external verification limits.
 
 <!-- reis-mobile:latest-release:end -->
 
@@ -225,10 +222,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, release, 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
@@ -236,6 +234,7 @@ After editing agents, skills or commands, restart Claude Code or Codex.
 /reis-mobile:test run the checkout unit tests    # Uses the existing runner, module or scheme
 /reis-mobile:test add XCTest coverage for cancellation # Tests the actual Swift type and its dependency seams
 /reis-mobile:test audit Espresso checkout tests  # Reviews assertions and synchronization without editing
+/reis-mobile:release audit both stores for the production variant # Evidence-backed readiness, read-only
 /reis-mobile:debate Riverpod or BLoC in this app? # Debate between the specialists, with a decision by lead-mobile
 /reis-mobile:debate --rounds 3 --external ...     # More rounds; --external adds Codex and Gemini, if installed
 ```
@@ -261,6 +260,26 @@ 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.
 
+### Release readiness
+
+`/reis-mobile:release [request]` audits the actual app artifacts for Flutter, native Android/iOS, React Native/Expo and Kotlin Multiplatform. `/reis-mobile release [request]` forwards to the same workflow. It resolves the app ID, flavor/scheme, environment, version/build, source revision, store/track and binary before evaluating readiness. Apps targeting both stores receive separate Android and iOS checks.
+
+The report lists each required gate as **pass**, **fail** or **unknown**, with evidence and next actions: identity, build, tests, analysis, version, signing, symbols, current store requirements, privacy, listing/localization and rollout/recovery. Any failed or unknown required gate means **NO-GO**. All gates passing means **GO**, or **GO WITH RISKS** when documented non-blocking risks remain. A packaged verdict helper enforces this decision rule; the specialist must still verify the evidence itself.
+
+The audit inspects existing files, artifacts and accessible CI/store records. It does not build, run tests, bump versions, tag, upload or change store settings by default. Missing CI results, upload history or portal confirmations remain unknown; local configuration is not proof that a check passed. Explicit execution requests retain their requested scope and prior authorization.
+
+```bash
+reis-mobile release --dir apps/mobile --json -- "audit Android production and iOS App Store"
+```
+
+The CLI only prepares routing, redacted git context, diagnostics and release reference paths. Its JSON includes `release.platforms` (candidate targets), `release.references`, `release.evidenceStatus: "unverified"` and `release.verdict: null`. Exit 0 does not approve a release. In Codex, ask it to run the CLI, read the returned instructions and follow `mobile-release`'s readiness contract; slash-command parity is not assumed.
+
+See the [readiness contract](skills/mobile-release/references/readiness.md) and [public Flutter sample audit](docs/examples/release-readiness.md) for the report format and evidence limits.
+
+### 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 +318,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` | ✅ |
@@ -309,7 +329,7 @@ The router never invents a specialist: if no agent serves the intent, it warns y
 | Full audit with several specialists | agent `lead-mobile` | ✅ |
 | Decide between two architectures with a real trade-off | `/reis-mobile:debate` | ✅ |
 | Dedicated test command (including XCTest and Espresso) | `/reis-mobile:test` | ✅ |
-| Check whether the app is ready for the store | `/reis-mobile:release` | 🔜 v0.8 |
+| Check whether the app is ready for the store with evidence per target | `/reis-mobile:release` | ✅ |
 | Consolidated decision by consensus between agents | `/reis-mobile:council` | 🔜 v0.10 |
 
 <details>
@@ -321,7 +341,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 +397,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 +414,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 +437,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`, `test` and `release` do not modify your project. `/reis-mobile:release` inspects existing release evidence and remains read-only unless execution is explicitly requested. 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 +445,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.
 
@@ -448,7 +472,7 @@ About 85 guides come from [flutter/skills](https://github.com/flutter/skills), [
 | v0.6.0 | Accessibility auditor and release engineer agents, `mobile-accessibility` and `mobile-release` skills, ANR, memory leak and deep link debugging guides | ✅ |
 | v0.7.0 | `/reis-mobile:test`, native tests (XCTest, Espresso) and project-specific specialist contracts | ✅ |
 | v0.7.1 | Update notices, single-source version and release automation | ✅ |
-| v0.8.0 | `/reis-mobile:release` with quality gates | ⏳ |
+| Unreleased | `/reis-mobile:release` with per-target evidence, required gates and deterministic readiness verdicts (previously planned for v0.8.0) | ✅ |
 | v0.9.0 | MCP server | ⏳ |
 | v0.10.0 | Multi-provider (OpenAI, Gemini, OpenRouter, Ollama) beyond the debate's `--external` | ⏳ |
 | v1.0.0 | First stable version: Flutter, Android, iOS and React Native | ⏳ |

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/agents/mobile-release-engineer.md

@@ -21,7 +21,7 @@ Use the [project brief](../docs/agent-context.md) once or reuse the supplied bri
 
 ## Produce the requested artifact
 
-- **Readiness:** apply the skill checklist to this release identity. Each gate is pass/fail/unknown with evidence and the responsible owner or next check. Verify current store requirements from official sources; local code cannot prove console approval or highest uploaded build number.
+- **Readiness:** apply the [readiness contract](../skills/mobile-release/references/readiness.md) and its verdict helper to this release identity. Unknown or failed required gates block readiness; evaluate each intended native artifact separately. Each gate is pass/fail/unknown with evidence and the responsible owner or next check. Verify current store requirements from official sources; local code cannot prove console approval or highest uploaded build number.
 - **Release notes:** establish the actual prior/current commit range. Map each user-facing change to commits/PRs, group by the app's feature names, preserve listing locales and check store limits from the reference. Unsupported claims stay out of the notes.
 - **Pipeline:** trace the existing jobs and artifact flow before proposing changes. Specify inputs, output artifact paths, secret names, build matrix and the dependency that prevents upload after failed checks. Keep build, signing and publishing steps independently identifiable.
 - **Rollout incident:** tie crash/ANR or adoption evidence to the affected build/cohort. Name the available halt, server flag or higher-build hotfix path from this app's deployment model, and state who remains exposed after a halt.

package/bin/reis-mobile.mjs

@@ -11,6 +11,7 @@ import { runDoctor } from '../core/diagnostics/doctor.mjs';
 import { runInit } from '../core/install/init.mjs';
 import { PLUGIN_ROOT } from '../core/paths.mjs';
 import { loadRegistry, validateRegistry } from '../core/registry/registry.mjs';
+import { releaseContext } from '../core/release/context.mjs';
 import { INTENT_IDS } from '../core/router/intents.mjs';
 import { route } from '../core/router/router.mjs';
 import { checkForUpdate, clearUpdateCache } from '../core/update/check.mjs';
@@ -28,6 +29,7 @@ Commands:
   review [prompt...]         Route a code review and collect the git context for it
   debug [problem...]         Route a build or runtime failure and report the toolchain it runs on
   test [request...]          Prepare test routing, git context and toolchain checks (does not run tests)
+  release [request...]       Prepare release evidence context (does not build or publish)
   agents | skills | stacks   List registered components
   validate                   Validate the plugin's agents, skills and stacks
   update-check               Check npm for a newer reis-mobile release
@@ -72,6 +74,7 @@ const COMMANDS = {
   review: commandReview,
   debug: commandDebug,
   test: commandTest,
+  release: commandRelease,
   agents: (options) => commandList('agents', options),
   skills: (options) => commandList('skills', options),
   stacks: (options) => commandList('stacks', options),
@@ -106,7 +109,7 @@ async function main(argv) {
   return (await command({ ...options, dir: project.projectDir, project, prompt: rest.join(' ') })) ?? 0;
 }
 
-const PROJECT_COMMANDS = new Set(['detect', 'doctor', 'route', 'review', 'debug', 'test']);
+const PROJECT_COMMANDS = new Set(['detect', 'doctor', 'route', 'review', 'debug', 'test', 'release']);
 
 async function commandUpdateCheck({ force, json }) {
   const result = await checkForUpdate({ force });
@@ -277,6 +280,26 @@ async function commandTest({ dir, project, base, prompt, json, lang }) {
   return 0;
 }
 
+/** Prepare release evidence; the specialist audits it before assigning a verdict. */
+async function commandRelease({ dir, project, prompt, json, lang }) {
+  const result = await route({ prompt, intent: 'release', projectDir: dir });
+  const context = collectReviewContext({ projectDir: dir });
+  const doctor = await runDoctor({ projectDir: dir });
+  const language = await resolveLanguage({ flag: lang });
+  const release = releaseContext(result.detection);
+  if (json) return print({ ...summarizeRoute(result), language, projectConfig: project.config?.path ?? null, context, doctor, release });
+
+  printProject(project, true);
+  printRoute(result);
+  printLanguage(language);
+  printContext(context);
+  console.log(`\nRelease platforms (verify) ${release.platforms.join(', ') || 'unknown'}`);
+  for (const reference of release.references) console.log(`  Reference ${reference}`);
+  console.log('\nRelease context prepared; readiness has not been evaluated. No builds, tests or uploads were executed.\n');
+  printDoctorChecks(doctor);
+  return 0;
+}
+
 async function commandList(kind, { json }) {
   const registry = await loadRegistry();
   const items = registry[kind];

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, release, debate or the right agent from a free-form request
+argument-hint: "[doctor | project | review | debug | test | release | debate | free-form request]"
+allowed-tools: ["Bash(node:*)", "Bash(git:*)", "Read", "Grep", "Glob", "Edit", "Write"]
 ---
 
 # reis-mobile
@@ -20,9 +20,11 @@ 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
+/reis-mobile:release [request]       Audits store readiness with evidence and a go/no-go verdict
 /reis-mobile:debate <question>       Debate between the specialists, with a decision by lead-mobile
 /reis-mobile <free-form request>     Forwards the request to the agent and skills for the detected stack
 ```
@@ -34,6 +36,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`.
@@ -50,6 +56,10 @@ Read `${CLAUDE_PLUGIN_ROOT}/commands/debate.md` and follow all of it, treating t
 
 Read `${CLAUDE_PLUGIN_ROOT}/commands/test.md` and follow all of it, treating the rest of the arguments (without the word `test`) as `$ARGUMENTS`. This entry point has the same behavior as `/reis-mobile:test`.
 
+## `release [request]`
+
+Read `${CLAUDE_PLUGIN_ROOT}/commands/release.md` and follow all of it, treating the rest of the arguments (without the word `release`) as `$ARGUMENTS`. This entry point has the same behavior as `/reis-mobile:release`.
+
 ## Any other text
 
 It is a free-form request, in English or Portuguese.

package/commands/release.md

@@ -0,0 +1,46 @@
+---
+description: Audit mobile release readiness with per-target evidence, store quality gates and a GO/GO WITH RISKS/NO-GO verdict
+argument-hint: "[request, version, variant or target store/track]"
+allowed-tools: ["Bash(node:*)", "Bash(git:*)", "Read", "Grep", "Glob", "WebFetch", "WebSearch"]
+---
+
+# reis-mobile release
+
+Arguments received: `$ARGUMENTS`
+
+## 1. Prepare context
+
+Run:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/bin/reis-mobile.mjs" release --dir "$PWD" -- "<request>"
+```
+
+Pass the request as a single literal argument after `--`, or omit it when empty. Use proper shell escaping: double quotes alone do not protect `$()`, backticks or embedded quotes. Never evaluate the request as shell code. The CLI forces `release` intent even if the request mentions a build failure. Stop and show the error if context preparation fails. Exit 0 means context preparation succeeded, not that a release is ready.
+
+Use `Project` (`detection.projectDir` in JSON) as the app root and `context.repoRoot` for git-relative paths. The CLI lists candidate release platforms and reference paths (`release.platforms` and `release.references`); they are unverified inventory, not a verdict. Inspect untracked files and required files omitted by diff truncation. The git diff alone is not release evidence.
+
+If the resolved directory does not exist or `detection.stack` is `unknown`, report NO-GO with unresolved identity/targets and the exact app path needed. Do not use a stack inferred from the prompt as evidence of an app on disk. Feed an empty `targets` array to the verdict helper rather than inventing artifacts.
+
+## 2. Bind the release to the app
+
+Read in order:
+
+1. `${CLAUDE_PLUGIN_ROOT}/docs/agent-context.md`; build or reuse the Project brief from the resolved app root.
+2. `${CLAUDE_PLUGIN_ROOT}/agents/<Agent>.md`, normally `mobile-release-engineer`.
+3. `${CLAUDE_PLUGIN_ROOT}/skills/<skill>/SKILL.md` for each routed skill, including `mobile-release`.
+4. `${CLAUDE_PLUGIN_ROOT}/skills/mobile-release/references/readiness.md` and each relevant release reference from the CLI output.
+
+Apply the selected role directly, or pass the existing brief to that specialist when delegation is available and appropriate. Do not repeat project discovery. Resolve the actual app ID, flavor/scheme/environment, version/build, source revision, store/track and built artifact for each target. For every field, record its source and distinguish configured values from values verified in the built artifact. Without an explicit request, inventory configured mobile targets and existing artifacts; leave ambiguous destinations and missing artifacts unknown.
+
+Flutter, React Native/Expo and Kotlin Multiplatform shipping to Android and iOS require both native release references and separate artifact checks. Confirm hosts/targets in the build configuration; a KMP framework build is not an iOS archive. Honor an explicitly limited store scope and name exclusions. Native folders generated by Expo need configuration inspection, not prebuild during the audit.
+
+## 3. Audit, evaluate and report
+
+Follow the required gates, evidence rules, verdict helper and report format in `readiness.md`. Reconcile local facts with existing artifact metadata, actual CI results and current official store requirements. Do not claim a store or CI check passed from local configuration alone. If external information is unavailable, identify the exact confirmation needed.
+
+Run `${CLAUDE_PLUGIN_ROOT}/skills/mobile-release/scripts/verdict.mjs` with the actual per-target gates on stdin as described in the reference. Missing evidence must remain unknown. Report its GO, GO WITH RISKS or NO-GO verdict with release identity, gate evidence, blockers, risks, unknowns, next actions and rollout/rollback. Its exit status is not a readiness verdict.
+
+The audit is read-only by default: no builds/tests, version bump, tag, upload, signing change or store-setting change. An explicit release execution request follows the selected agent's scope rules and prior authorization; never execute a publishing lane just because it exists. Distinguish commands inspected/prepared from those actually executed.
+
+Write user-facing prose in the CLI's `Language`: `en` is English, `pt` is Brazilian Portuguese; with `-` or `null`, follow the user's language. Keep paths, gate IDs, verdicts and quoted output unchanged.

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',
 };
 
 /**