reis-mobile 0.9.0 → 0.10.1

package/.claude-plugin/marketplace.json

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

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "reis-mobile",
-  "version": "0.9.0",
+  "version": "0.10.1",
   "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,43 @@ Format based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). The pr
 
 ## [Unreleased]
 
+## [0.10.1] - 2026-11-04
+
+### Added
+
+- `mobile-ui-ux-designer` agent and `mobile-ui-ux` topic skill for mobile journeys, wireframes, design tokens, component states and evidence-based interface reviews across all five stacks.
+- English and Portuguese `design` routing with platform skill selection and regression coverage for architecture, accessibility, tests and unrelated terms.
+- Apple design reading workflow linked to `dickwu/apple-design-skill` at a recorded revision and to official HIG topics. Upstream content is linked, not vendored, because the inspected revision declares no redistribution license.
+
+### Changed
+
+- The debate now invokes `lead-mobile` for participant selection before the rounds and again for final synthesis. The candidate table includes every specialist, including UI/UX, accessibility and release, with explicit participant validation and a persisted selection rationale.
+- All five platform skills now route design work and link the UI/UX workflow and Apple-target reference.
+
+### Fixed
+
+- `lead-mobile` now includes the UI/UX designer in its delegation table. A registry test requires every other registered agent, including manual specialists, to appear and rejects unknown agents or self-delegation.
+
+## [0.10.0] - 2026-11-04
+
+### Added
+
+- `mobile-ci` topic skill for deployment pipelines across all five stacks, with the setup, Match, beta, release and Snapshot guides plus Xcode Cloud documentation imported from `greenstevester/fastlane-skill` (MIT), attributed and pinned to their upstream revision.
+
+- Four topic skills, each with Flutter, Android, iOS, React Native and Kotlin Multiplatform references: `mobile-privacy` for consent and data lifecycle, `mobile-networking` for API integration and request recovery, `mobile-auth` for identity/session flows, and `mobile-notifications` for push/local notification lifecycles.
+- English and Portuguese `privacy`, `networking`, `auth` and `notifications` intents, handled by the existing staff engineer, with five-stack routing, prompt discovery and explicit-override tests.
+- `mobile-billing`, `mobile-migration`, `mobile-analytics` and `mobile-hardware` topic skills, each with Flutter, Android, iOS, React Native and Kotlin Multiplatform references: in-app purchases verified by the backend before acknowledgement and recovered after process death; migrations planned as buildable steps, with on-device data that survives skipped releases and interrupted launches; tracking plans with typed events, identity reset on sign-out and consent-gated collection; device hardware from the availability check to the release of the resource, with real-device test matrices.
+- English and Portuguese `billing`, `analytics` and `hardware` intents, handled by `mobile-staff-engineer`. `mobile-migration` joins the existing `migration` route. Plain "analytics" still routes to observability.
+
+### Changed
+
+- Authentication requests now have a dedicated `auth` intent instead of relying on security vocabulary. Explicit security audits retain the security workflow.
+- `mobile-staff-engineer` serves the `billing`, `analytics` and `hardware` intents and loads `mobile-migration` for migration plans.
+
+### Fixed
+
+- The router counted any word starting with "pr" as a review request, so prompts such as "implementar paywall premium" or "definir funil de conversão do produto" went to review. "PR" and "PRs" now count only as whole words.
+
 ## [0.9.0] - 2026-10-13
 
 ### Added

package/README.md

@@ -23,7 +23,7 @@ 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.
 
-👥 **21 agents and 17 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, releases, performance budgets, offline sync and production observability.
+👥 **22 agents and 27 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, a UI/UX designer, an accessibility auditor, a release engineer and a lead. Topic skills cover the five stacks with focused references for debugging, tests, security, Firebase, accessibility, releases, performance budgets, offline sync, production observability, privacy, networking, authentication, notifications, in-app purchases, migrations, product analytics and device hardware.
 
 🧩 **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.
 
@@ -44,28 +44,22 @@ 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.9.0
+### v0.10.1
 
 #### Added
 
-- `core/providers/`: the multi-provider layer. Six external providers — the `codex` and `gemini` CLIs plus the OpenAI, Gemini, OpenRouter and Ollama HTTP APIs — described as data (endpoint, credential variables, request shape, model catalog), so adding one touches no command. Status, model and allowlist resolution make no network call: a CLI is found by scanning `PATH`, an HTTP provider by its credential variable.
-- `reis-mobile providers [--all] [--json]` lists every provider with the evidence behind its status (`ready`, `local`, `missing`, `disabled`, `blocked`), its endpoint and the resolved model. `reis-mobile providers --models` asks each provider which models it serves, so no model id is ever shipped as a default.
-- `reis-mobile consult [--providers a,b] [--model <id>] [--file <path>] [--timeout <ms>] <question>` asks the selected providers the same question in parallel. The core performs the call, so no API key passes through the conversation; the question is redacted on the way out and every answer on the way in. Each requested provider is reported with its own typed status — `ok`, `unavailable`, `no-model`, `timeout`, `error` — and the exit code is 1 only when nobody answered.
-- `/reis-mobile:consult [options] <question>`, also reachable as `/reis-mobile consult ...`: routes the question through the stack's specialist, requires its own position first, builds a self-contained briefing in `.reis-mobile/consults/`, consults the providers and then reconciles every outside claim against the code as confirmed with `file:line`, unverifiable or wrong.
-- `providers:` in `.reis-mobile/config.yaml`: the allowlist of external providers a repository accepts, committed with the repository. An absent key allows all, an empty list allows none, and a blocked provider says so instead of failing.
-- `providers.<id>.model` and `providers.<id>.enabled` in `~/.config/reis-mobile/config.json`, with precedence `--model`, then the provider's model variable (`OPENAI_MODEL`, `GEMINI_MODEL`, `OPENROUTER_MODEL`, `OLLAMA_MODEL`), then the config file.
-- `reis-mobile doctor` lists the configured providers under Integrations, with a single informational row when none is configured. It still makes no network call.
+- `mobile-ui-ux-designer` agent and `mobile-ui-ux` topic skill for mobile journeys, wireframes, design tokens, component states and evidence-based interface reviews across all five stacks.
+- English and Portuguese `design` routing with platform skill selection and regression coverage for architecture, accessibility, tests and unrelated terms.
+- Apple design reading workflow linked to `dickwu/apple-design-skill` at a recorded revision and to official HIG topics. Upstream content is linked, not vendored, because the inspected revision declares no redistribution license.
 
 #### Changed
 
-- `/reis-mobile:debate --external` selects providers through the core instead of probing with `command -v`, accepts `--providers a,b`, and no longer needs `Bash(codex:*)` or `Bash(gemini:*)`: every provider call goes through the CLI. Behavior without a ready provider is unchanged — the debate carries on with the agents alone.
-- CLI providers are asked for an opinion, not for work: `codex exec` now runs with `--sandbox read-only` and `gemini` with `--approval-mode plan`, both in a temporary working directory that is removed afterwards. The debate's previous invocation granted write access and the user's repository as a workspace, neither of which a second opinion needs.
-- `/reis-mobile:review` points at `/reis-mobile:consult` when a finding should be cross-checked outside the session, and still never sends project context itself.
+- The debate now invokes `lead-mobile` for participant selection before the rounds and again for final synthesis. The candidate table includes every specialist, including UI/UX, accessibility and release, with explicit participant validation and a persisted selection rationale.
+- All five platform skills now route design work and link the UI/UX workflow and Apple-target reference.
 
 #### Fixed
 
-- `/reis-mobile:debate --external` could not reach Codex at all on current CLI versions: `codex exec --full-auto` is rejected with `unexpected argument '--full-auto' found`, and the call ran outside a Git repository without `--skip-git-repo-check`. The provider catalog now carries the invocation verified against `codex exec --help`.
-- A failing CLI provider reported its opening banner (`YOLO mode is enabled...`) instead of the cause. The reported line is now the first one that names a failure, falling back to the last line of stderr.
+- `lead-mobile` now includes the UI/UX designer in its delegation table. A registry test requires every other registered agent, including manual specialists, to appear and rejects unknown agents or self-delegation.
 
 <!-- reis-mobile:latest-release:end -->
 
@@ -301,9 +295,9 @@ See the [readiness contract](skills/mobile-release/references/readiness.md) and
 
 ### 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/`.
+`/reis-mobile:debate` first asks `lead-mobile` to select three relevant specialists and explain each assignment. Every specialist is eligible, including UI/UX, accessibility and release; `--agents` supplies explicit choices for the lead to validate. 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` returns to analyze the rounds, resolve disagreements and deliver the decision with an action plan. The lead selects and moderates but does not debate. The rounds are stored in `.reis-mobile/debates/`.
 
-Participants vary along two axes at once. The **role** gives each one a different incentive: `flutter-architect` defends layer boundaries, `flutter-performance-engineer` is hostile to indirection, `flutter-test-engineer` wants injection seams the other two consider noise. The **model** keeps that disagreement from staying on the surface — the command spreads `opus` and `sonnet` across the participants, because three instances of the same model inherit the same blind spots and tend to converge for reasons that have nothing to do with your question. With `--external`, a third axis comes in: outside **providers**, in separate processes.
+Participants vary by role and model. The lead uses the command's `opus`/`sonnet` assignments and selects at least two models automatically; valid explicit `--agents` choices are preserved, with any same-model limitation disclosed. Model diversity does not guarantee independent reasoning: conclusions still require evidence. The command runs the selected participants and records the selection rationale with the context. With `--external`, outside providers join through the existing provider layer; the lead does not enable them on its own.
 
 It is expensive: several agents over two rounds. Use it for architecture decisions with a real trade-off — *migrate to Riverpod*, *offline-first with Firestore or a local cache*, *native plugin or an off-the-shelf package* — and not for questions with a single answer, where `/reis-mobile <request>` solves it for less.
 
@@ -389,6 +383,7 @@ The router never invents a specialist: if no agent serves the intent, it warns y
 | 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` | ✅ |
 | Check release readiness, write release notes or set up CI/CD | agent `mobile-release-engineer` | ✅ |
+| Set up fastlane lanes, Match, TestFlight or automated screenshots | skill [`mobile-ci`](skills/mobile-ci/SKILL.md) | ✅ |
 | Set startup, frame, memory and battery budgets and guard them in CI | skill `mobile-performance` | ✅ |
 | Make the app work offline, queue writes and resolve conflicts | skill `mobile-offline-sync` | ✅ |
 | Get usable crashes, errors, traces and release-health alerts in production | skill `mobile-observability` | ✅ |
@@ -407,8 +402,8 @@ 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 | 21 agents and 17 mobile skills |
-| **Context cost** | Zero | ~4,700 fixed tokens (agent and skill descriptions), no hooks |
+| **Specialists** | None | 22 agents and 27 mobile skills |
+| **Context cost** | Zero | ~5,500 fixed tokens (agent and skill descriptions), no hooks |
 | **Best for** | General tasks | Teams and developers working on mobile apps |
 
 **In short:** Claude Code already knows how to code. reis-mobile makes it look at what matters in a mobile app.
@@ -466,13 +461,25 @@ For domain knowledge that code cannot reveal, optionally commit `.reis-mobile/pr
 | `kmp-architect` | Kotlin Multiplatform | architecture, offline | 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-ui-ux-designer` | all | design | Mobile journeys, wireframes, design tokens, adaptive layouts and evidence-based UI/UX reviews |
 | `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, observability | Go/no-go readiness, versions and signing, crash symbols, release notes and store copy, CI/CD, staged rollout, production crash and release-health signals |
-| `mobile-staff-engineer` | all | debug, architecture, performance, test, security, migration, dependency, build, offline, observability | Cross-toolchain diagnosis and migrations when no stack specialist owns the intent |
+| `mobile-staff-engineer` | all | debug, architecture, performance, test, security, migration, dependency, build, offline, observability, privacy, networking, auth, notifications, billing, analytics, hardware | Cross-toolchain diagnosis, migrations and capability workflows 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 KMP app, to `kmp-performance-engineer`. `accessibility` goes to `mobile-accessibility-auditor`, `release`, `deployment` and `observability` to `mobile-release-engineer` on every stack, and `offline` to the stack's architect.  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`. `design` goes to `mobile-ui-ux-designer`, `accessibility` goes to `mobile-accessibility-auditor`, `release`, `deployment` and `observability` to `mobile-release-engineer` on every stack, and `offline` to the stack's architect.  Other intents without a stack specialist, such as `debug`, go to `mobile-staff-engineer`.
+
+### UI/UX design
+
+Ask Claude Code to "use reis-mobile:mobile-ui-ux-designer to redesign this screen", or use `mobile-ui-ux` in a skill-capable host such as Codex. From a mobile app directory, inspect routing with:
+
+```bash
+reis-mobile route "review the UI/UX of this screen"
+reis-mobile route "create a mobile design system"
+```
+
+The workflow covers journeys, wireframes, tokens, component states, adaptive layouts and implementation when requested. Existing platform skills link it too. Apple-target work includes a reading guide for [dickwu/apple-design-skill](https://github.com/dickwu/apple-design-skill) and official HIG pages. The upstream repository has no explicit redistribution license at the inspected revision, so its content is linked rather than bundled; the new guides are original project content. Current Apple claims require source verification, and Android retains its own conventions.
 
 ### Skills
 
@@ -485,20 +492,46 @@ Every skill starts with `mobile-`. **Topic** skills cover every stack with one r
 | `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, OAuth/OIDC and PKCE |
+| `mobile-ui-ux` | Journeys, wireframes, visual hierarchy, tokens, component states and Apple HIG reference workflow | design | Flutter, Android, iOS, React Native, KMP and external Apple design reading |
 | `mobile-accessibility` | Screen readers, touch targets, text scaling, contrast, localization | accessibility | Flutter (Semantics), Android (Compose and Views), iOS (SwiftUI and UIKit), React Native, KMP, localization and RTL |
 | `mobile-release` | Release readiness, store copy, billing and CI/CD | release, deployment | Flutter, Android, iOS, React Native, KMP, release notes and store listing, in-app purchases, CI/CD |
+| `mobile-ci` | CI/CD and fastlane setup, Match, beta, release and Snapshot | deployment | Flutter, Android, iOS, React Native, KMP, imported fastlane guides and Xcode Cloud |
 | `mobile-performance` | Startup, rendering, memory, battery, app size and regression gates | performance | Flutter, Android, iOS, React Native, KMP, background execution and battery |
 | `mobile-offline-sync` | Local store, outbox, idempotency, conflict resolution, reconnection | offline | Flutter, Android, iOS, React Native, KMP |
 | `mobile-observability` | Crashes, errors, breadcrumbs, traces, alerts, sampling and privacy | observability | Flutter, Android, iOS, React Native, KMP |
+| `mobile-privacy` | Consent lifecycle, SDK collection, account/data deletion and retention | privacy | Flutter, Android, iOS, React Native, KMP |
+| `mobile-networking` | API contracts, cancellation, pagination, refresh coordination and resumable transfers | networking | Flutter, Android, iOS, React Native, KMP |
+| `mobile-auth` | Sign-in, passkeys, recovery, provider linking and session transitions | auth | Flutter, Android, iOS, React Native, KMP |
+| `mobile-notifications` | Push/local notifications, token bindings, permissions and cold-start taps | notifications | Flutter, Android, iOS, React Native, KMP |
+| `mobile-billing` | In-app purchases, subscriptions, backend verification, acknowledgement and restore | billing | Flutter, Android, iOS, React Native, KMP |
+| `mobile-migration` | Toolchain and library upgrades, incremental UI moves and on-device data migrations | migration | Flutter, Android, iOS, React Native, KMP |
+| `mobile-analytics` | Tracking plans, typed events, funnels, analytics identity and consent-gated collection | analytics | Flutter, Android, iOS, React Native, KMP |
+| `mobile-hardware` | Camera, Bluetooth and BLE, NFC, location, sensors, scanning and haptics | hardware | Flutter, Android, iOS, React Native, KMP |
 | `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-flutter` | Flutter and Dart specifics | design, 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 | design, 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 | design, performance, release, accessibility | UI and navigation, data and networking, platform features, performance and release |
+| `mobile-rn` | React Native and Expo specifics | design, performance, release, accessibility | UI and navigation, data and networking, platform features, performance and release |
+| `mobile-kmp` | Kotlin Multiplatform shared and target boundaries | design, 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`.
+Skills marked — are triggered by Claude Code when the request matches their description, for example *"configure Firestore rules"* → `mobile-firebase`. Notification requests route to `mobile-notifications`, which links Firebase guidance when FCM is the installed provider.
+
+The seven capability intents (`privacy`, `networking`, `auth`, `notifications`, `billing`, `analytics` and `hardware`) select `mobile-staff-engineer` and the matching topic skill; `mobile-migration` joins the existing `migration` route. Use these from your mobile app directory:
+
+```bash
+reis-mobile route "implement account deletion"
+reis-mobile route "implement resumable uploads"
+reis-mobile route "implement sign-in with passkeys"
+reis-mobile route "implement local notifications"
+reis-mobile route "add in-app purchases"
+reis-mobile route "create a tracking plan"
+reis-mobile route "connect to a Bluetooth device"
+reis-mobile route "migrate from BLoC to Riverpod"
+reis-mobile route --intent auth "review the session lifecycle"
+```
+
+The CLI returns the selected agent and instruction paths; it does not implement a login, delete an account, send a notification or make a purchase. An explicit intent takes precedence over the prompt. Existing security audits, tests and release work retain their own routes, and a plain "analytics" request still goes to `mobile-observability`. When a short prompt is ambiguous, pass `--intent` or invoke the skill directly in the host.
 
 About 85 guides come from [flutter/skills](https://github.com/flutter/skills), [dart-lang/skills](https://github.com/dart-lang/skills), [evanca/flutter-ai-rules](https://github.com/evanca/flutter-ai-rules) and [android/skills](https://github.com/android/skills), unchanged and credited in [THIRD_PARTY_NOTICES.md](THIRD_PARTY_NOTICES.md).
 
@@ -514,7 +547,7 @@ About 85 guides come from [flutter/skills](https://github.com/flutter/skills), [
 
 **Exception: external providers.** Two workflows, and only these two, send project context to a third party: `/reis-mobile:debate --external` and `/reis-mobile:consult`. Both state which providers receive it, and both are opt-in — no other command calls a provider. What leaves is the briefing, including the code excerpts you include; each provider has its own data policy. The question and every answer pass through `redact.mjs`, which is a protection layer and not a guarantee: read the briefing before sending it. API keys are read from the environment by the CLI and never enter the conversation, and `providers:` in `.reis-mobile/config.yaml` lets a team restrict which providers a repository allows. CLI providers (`codex`, `gemini-cli`) are asked for an opinion, not for work: they run in read-only mode (`codex exec --sandbox read-only`, `gemini --approval-mode plan`) inside a temporary directory, never in your repository.
 
-**Context cost.** Claude Code loads the descriptions of 21 agents and 17 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.
+**Context cost.** Claude Code loads the descriptions of 22 agents and 27 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.
 
@@ -544,7 +577,8 @@ About 85 guides come from [flutter/skills](https://github.com/flutter/skills), [
 | v0.7.3 | `/reis-mobile:release` with per-target evidence, required gates and deterministic readiness verdicts (previously planned for v0.8.0) | ✅ |
 | v0.8.0 | `mobile-performance`, `mobile-offline-sync` and `mobile-observability` topic skills with a reference per stack, plus background execution, OAuth/PKCE, billing lifecycle and localization references | ✅ |
 | v0.9.0 | Multi-provider layer (OpenAI, Gemini, OpenRouter, Ollama and the Codex/Gemini CLIs), `reis-mobile providers`, `reis-mobile consult` and `/reis-mobile:consult` — previously planned for v0.10.0 | ✅ |
-| v0.10.0 | MCP server | ⏳ |
+| v0.10.0 | `mobile-privacy`, `mobile-networking`, `mobile-auth` and `mobile-notifications` topic skills with a reference per stack, plus the `privacy`, `networking`, `auth` and `notifications` intents | ✅ |
+| v0.11.0 | MCP server | ⏳ |
 | v1.0.0 | First stable version: Flutter, Android, iOS and React Native | ⏳ |
 
 ---
@@ -576,7 +610,7 @@ The plugin's skills live in the `reis-mobile:` namespace and do not conflict, bu
 Yes: `reis-mobile init eng` installs the plugin in Codex too. See [installation](#install). Installation does not confirm parity with the Claude Code agents and commands; the `reis-mobile` CLI can also be run by Codex to get diagnostics and context.
 
 **Does it work in Cursor?**
-The Cursor integration has not been validated yet. The MCP server remains on the roadmap for v0.8.0.
+The Cursor integration has not been validated yet. The MCP server remains on the roadmap for v0.11.0.
 
 **What does reis-mobile send outside my machine?**
 The project analysis commands do not make network requests. The update hook and `reis-mobile update-check` request the public npm package metadata without sending project files or identifiers. What the model reads during `/reis-mobile:review` follows the same rules as any Claude Code session.
@@ -612,6 +646,7 @@ Questions: [Discussions](https://github.com/wrsilva/reis-mobile/discussions). Wh
 
 ## Attribution
 
+- **[greenstevester/fastlane-skill](https://github.com/greenstevester/fastlane-skill)** (MIT): five fastlane guides and Xcode Cloud documentation in [`mobile-ci`](skills/mobile-ci/SKILL.md). The source revision and license are recorded in [Third-Party Notices](THIRD_PARTY_NOTICES.md).
 - **[flutter/skills](https://github.com/flutter/skills)** (BSD-3-Clause): 25 Flutter skills.
 - **[dart-lang/skills](https://github.com/dart-lang/skills)** (BSD-3-Clause): 8 Dart skills.
 - **[evanca/flutter-ai-rules](https://github.com/evanca/flutter-ai-rules)** (MIT): 28 Flutter, testing and Firebase skills.

package/THIRD_PARTY_NOTICES.md

@@ -1,5 +1,38 @@
 # Third-Party Notices
 
+## greenstevester/fastlane-skill
+
+- Source: https://github.com/greenstevester/fastlane-skill
+- Revision: `cab4eff8e678391671916228d7b6446d438da4a9`
+- License: MIT
+- Integrated into `mobile-ci` as references; no standalone upstream skills are registered.
+- Adapted files under `skills/`: `setup-fastlane` → `mobile-ci/references/fastlane/setup-fastlane.md` and `mobile-ci/references/fastlane/xcode-cloud.md` (upstream `docs/xcode-cloud.md`); `match` → `mobile-ci/references/fastlane/match.md`; `beta` → `mobile-ci/references/fastlane/beta.md`; `release` → `mobile-ci/references/fastlane/release.md`; `snapshot` → `mobile-ci/references/fastlane/snapshot.md`.
+- Adaptation: removed skill frontmatter, added attribution and relocated the Xcode Cloud link. Original guide bodies are otherwise preserved; project-specific integration guidance lives in `mobile-ci/SKILL.md`.
+
+```text
+MIT License
+
+Copyright (c) 2024 greenstevester
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+```
+
 reis-mobile is distributed under the MIT License (see [LICENSE](LICENSE)). The skills listed below were derived from third-party projects and remain under their original licenses. Each of these skills declares `source` and `license` in its `SKILL.md` frontmatter.
 
 Changes made by reis-mobile: every third-party skill was moved into a reis-mobile skill (`mobile-test`, `mobile-firebase`, `mobile-code-review`, `mobile-debug`, `mobile-security`, `mobile-architecture`, `mobile-flutter`, `mobile-android`). Its instructions are unchanged apart from a leading attribution line and the removed frontmatter; skills that shipped extra files (references, scripts, examples) moved as whole folders with the instructions in `GUIDE.md`, so their relative links still work. Each section lists the upstream skill and the file that holds it now. Some copies correspond to earlier revisions of the upstream files.
@@ -320,3 +353,11 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    See the License for the specific language governing permissions and
    limitations under the License.
 ```
+
+## External Apple design reading (not redistributed)
+
+Source: https://github.com/dickwu/apple-design-skill
+
+Inspected revision: `ff4ebddf0488598723a82bfdce1afb04de0b1c44` on 2026-11-04. Referenced by `mobile-ui-ux` through `references/apple-design.md`.
+
+The inspected repository contains no LICENSE file or explicit redistribution license. Its README attributes the reproduced Human Interface Guidelines text to Apple Inc. No upstream skill text, scripts or HIG snapshots are included here. This is an external reference, not an MIT-licensed import; no third-party license text is available to reproduce. The local UI/UX workflow and platform references are original project content.

package/agents/lead-mobile.md

@@ -14,7 +14,7 @@ Read the [project brief](../docs/agent-context.md) once and build it for the act
 
 ## Assign bounded ownership
 
-Agents use the `reis-mobile:` prefix in the Agent tool. Choose by stack and deliverable:
+Every other agent shipped in this plugin is available for your delegation, including agents with manual routing. Keep the assignment table complete when specialists are added or renamed; do not delegate to yourself. Agents use the `reis-mobile:` prefix in the Agent tool. Choose by stack and deliverable:
 
 | Assignment | Specialist |
 |---|---|
@@ -34,6 +34,7 @@ Agents use the `reis-mobile:` prefix in the Agent tool. Choose by stack and deli
 | 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` |
+| User journeys, wireframes, visual hierarchy, design tokens and interface states | `reis-mobile:mobile-ui-ux-designer` |
 | Assistive-technology journey and control semantics | `reis-mobile:mobile-accessibility-auditor` |
 | Release identity, artifact gates, notes or pipeline | `reis-mobile:mobile-release-engineer` |
 | Production crash, error and release-health signals | `reis-mobile:mobile-release-engineer` |
@@ -50,7 +51,7 @@ Give every assignment the shared brief plus: question to resolve, owned paths/sy
 
 Examples of dependency ordering:
 
-- Feature: architecture contracts first, then implementation and test cases against those contracts.
+- Feature: involve the UI/UX designer when screens or journeys change, align the interaction design with architecture contracts, then implement and test against those contracts.
 - Native failure: bridge request/lifecycle trace plus platform stack investigation, then one coordinated correction.
 - Audit: split by distinct risk/path and merge overlapping evidence; do not commission duplicate whole-app checklists.
 
@@ -60,9 +61,19 @@ If delegation is unavailable, follow the same boundaries sequentially and state
 
 Require actual paths/symbols, a trigger or violated contract, evidence level and the next verification. Resolve conflicting claims by inspecting the decisive code or running the discriminating check. Merge findings with one root cause even when their wording differs. An unmeasured performance suspicion cannot outweigh a reproduced correctness regression without an explicit reason.
 
+## Debate selection
+
+When `/reis-mobile:debate` invokes you with `phase: selection`, choose who will debate before any rounds run. Use the supplied question, project evidence, stack/native targets, flags and complete candidate/model table from the command. Every other registered plugin agent is eligible, including UI/UX, accessibility, release and manual specialists; choose by the trade-off rather than always selecting architecture roles.
+
+Return a selection plan with each specialist's exact name, model from the supplied table, assigned question, rationale, evidence scope and any unresolved constraint. Automatically select three distinct relevant specialists spanning at least two models. Preserve valid explicit `--agents` choices and their table models; reject unknown names, duplicates, fewer than two distinct participants or yourself as a debater. Disclose an explicit same-model selection without overriding it. If no relevant automatic trio meets the model rule, report the limitation to the caller rather than inventing relevance.
+
+Do not argue a position or preselect the winning solution during selection: the first round must remain blind. Do not launch agents or providers, write round files or change app code in this phase. Return the plan to the command, which validates it and runs the rounds. If the caller reports invalid plan fields, correct the plan before any round starts.
+
 ## Debate moderation
 
-When `/reis-mobile:debate` invokes you, you do not delegate: the rounds already happened and sit in `.reis-mobile/debates/<id>/rounds/`. Read all of them before writing anything.
+When `/reis-mobile:debate` invokes you with `phase: synthesis`, return as moderator after the rounds. Read the original question/context, selection plan, all completed files in `.reis-mobile/debates/<id>/rounds/` and any missing/failed participant statuses before writing the decision. Do not delegate, select new participants, start rounds or change app code in this phase. Missing responses are gaps in evidence, not agreement.
+
+The two debate phases override the general delegation workflow above. You select at the beginning and decide at the end; you never submit a debating position.
 
 Your job is to decide, not to declare a tie:
 

package/agents/mobile-release-engineer.md

@@ -28,6 +28,8 @@ Use the [project brief](../docs/agent-context.md) once or reuse the supplied bri
 
 ## Scope and decision
 
+For pipeline implementation and fastlane automation, load [mobile-ci](../skills/mobile-ci/SKILL.md) and its relevant platform and task references.
+
 A release audit authorizes inspection and preparation. Version bumps, tags and publishing follow the user's requested scope; do not infer an upload from a readiness question. For an explicitly requested deployment, complete the reviewable preparation and reuse existing authorization. Avoid executing a lane before inspecting whether it publishes.
 
 Return the release identity, GO/GO WITH RISKS/NO-GO verdict where relevant, gates with evidence, exact prepared commands/artifacts and outstanding external state. Define rollout monitoring using the project's metrics and thresholds; proposed thresholds must be labeled as proposals. Never imply that halting store distribution removes a binary already installed.

package/agents/mobile-staff-engineer.md

@@ -1,10 +1,10 @@
 ---
 name: mobile-staff-engineer
-description: Use this agent for senior-level guidance across Flutter/Dart, Android (Kotlin) and iOS (Swift) — debugging complex build and runtime issues, architecture decisions for native apps, migrations, dependency and build problems, CI/CD and release pipelines, security and cross-platform trade-offs. Typical triggers are "the Android build broke after upgrading Gradle", planning a payment flow and choosing between native and cross-platform approaches.
+description: Use this agent for senior-level guidance across Flutter/Dart, Android (Kotlin) and iOS (Swift) — debugging complex build and runtime issues, architecture decisions for native apps, migrations, dependency and build problems, CI/CD and release pipelines, security, privacy, API integration, authentication, notifications, in-app purchases, product analytics, device hardware and cross-platform trade-offs. Typical triggers are "the Android build broke after upgrading Gradle", planning a payment flow and choosing between native and cross-platform approaches.
 model: inherit
 color: blue
 tools: ["Read", "Grep", "Glob", "Bash"]
-intents: [debug, architecture, performance, test, security, migration, dependency, build, offline, observability]
+intents: [debug, architecture, performance, test, security, migration, dependency, build, offline, observability, privacy, networking, auth, notifications, billing, analytics, hardware]
 stacks: ["*"]
 ---
 
@@ -14,6 +14,20 @@ Read the [project brief](../docs/agent-context.md) once or reuse the supplied br
 
 ## Build a causal chain
 
+For privacy work, load [mobile-privacy](../skills/mobile-privacy/SKILL.md). Follow its implementation and verification workflow using actual app objects; the failure record below applies when diagnosing a defect, not to every capability request.
+
+For API integration and network lifecycle work, load [mobile-networking](../skills/mobile-networking/SKILL.md) and bind its request/cancellation contract to the actual client and repository.
+
+For identity and session flows, load [mobile-auth](../skills/mobile-auth/SKILL.md) and trace the provider, session owner and account-scoped data boundaries.
+
+For push or local notification flows, load [mobile-notifications](../skills/mobile-notifications/SKILL.md) and trace token ownership, app lifecycle and authorized tap navigation.
+
+For in-app purchases and subscriptions, load [mobile-billing](../skills/mobile-billing/SKILL.md) and trace the purchase listener, backend verification and every entitlement read.
+
+For product analytics, load [mobile-analytics](../skills/mobile-analytics/SKILL.md) and trace each event from its trigger through the app's analytics boundary to the destination.
+
+For camera, Bluetooth, NFC, location, sensors or haptics, load [mobile-hardware](../skills/mobile-hardware/SKILL.md) and trace each capability from its availability check to the release of the resource.
+
 1. Recover the exact command, working directory, app root, variant/scheme and first actionable error. Locate the failure phase: resolution, generation, compilation, linking, signing, packaging, startup or runtime.
 2. Read the last relevant change and the versions actually selected by wrappers, lock files and CI. Compare local and CI toolchain evidence; a declared dependency constraint is not necessarily the resolved version.
 3. Trace the failing symbol/configuration from the error to its source file or build input. In cross-platform apps, distinguish Dart/JavaScript callers, generated integration code and native implementation. Identify the source of generated files before proposing an edit.
@@ -22,7 +36,7 @@ Read the [project brief](../docs/agent-context.md) once or reuse the supplied br
 
 ## Migrations need a compatibility contract
 
-Record the current and target toolchain/dependency versions from verified sources, minimum supported platforms, affected native modules and generated code. Split the migration into buildable steps with a check after each. Preserve the app's existing state, storage and public API contracts unless changing them is the objective.
+Load [mobile-migration](../skills/mobile-migration/SKILL.md) for the step plan, on-device data migrations and rollout. Record the current and target toolchain/dependency versions from verified sources, minimum supported platforms, affected native modules and generated code. Split the migration into buildable steps with a check after each. Preserve the app's existing state, storage and public API contracts unless changing them is the objective.
 
 Compare two viable options only when the choice matters. Name the actual module/type changed by each, operational cost, reversible step and condition that would invalidate the decision. Avoid broad prescriptions such as replacing the state library or upgrading every dependency to solve one failure.
 

package/agents/mobile-ui-ux-designer.md

@@ -0,0 +1,33 @@
+---
+name: mobile-ui-ux-designer
+description: Use this agent to design, critique or improve mobile UI/UX across Flutter, Android, iOS, React Native and Kotlin Multiplatform. It covers user journeys, wireframes, navigation, visual hierarchy, typography, semantic design tokens, component states and adaptive layouts. Typical requests include "review this design", "redesign this screen", "create a mobile design system" and Apple HIG reviews of screenshots, Figma exports or UI code. It produces evidence-based findings or an implementation-ready design and implements changes when requested.
+model: inherit
+color: purple
+tools: ["Read", "Grep", "Glob", "Bash", "Edit", "Write", "WebFetch", "WebSearch"]
+intents: [design]
+stacks: ["*"]
+---
+
+You own the experience of completing a mobile task, from entry through success and recovery. Design decisions must fit the product, the user's platform and the existing implementation.
+
+Read the [project brief](../docs/agent-context.md) once or reuse the caller's verified brief. Apply [mobile-ui-ux](../skills/mobile-ui-ux/SKILL.md), its actual stack reference and [mobile-accessibility](../skills/mobile-accessibility/SKILL.md) for the controls in scope. For Apple targets, load the [Apple design reference](../skills/mobile-ui-ux/references/apple-design.md). Do not assume a cross-platform renderer supplies native behavior automatically.
+
+## Establish the design boundary
+
+Inspect routes, shared components, theme tokens, content and supported targets. Identify the user's task, audience, entry and exit, primary action, constraints and existing brand. Label assumptions when the product brief leaves these open. For a new screen, describe proposed symbols as new rather than inventing existing paths.
+
+Use screenshots and Figma artifacts to examine visible hierarchy; use source to trace tokens and behavior; use a running app to confirm gestures, focus and transitions. State which evidence exists. A screenshot alone does not prove touch dimensions, contrast compliance, navigation behavior or screen-reader support.
+
+## Deliver the experience
+
+1. Trace the journey and remove unnecessary decisions or repeated input. Keep back, cancellation and recovery predictable.
+2. Specify the layout at compact and expanded widths, keyboard-visible behavior, long translated content and large text. Include loading, empty, error, success and disabled states where relevant.
+3. Reuse semantic color, type, spacing and component tokens. Explain any new visual direction using the product's content and audience. Keep platform controls recognizable and locate brand expression deliberately.
+4. Map each decision to the real component and platform API, checking the installed toolkit version before proposing implementation details. Separate Apple guidance from Android conventions.
+5. When implementation is requested, edit the responsible component and verify affected callers. When review alone is requested, return findings and concrete changes without changing files.
+
+## Evidence and handoff
+
+For a review, give prioritized findings with affected journey, `path:line` or artifact location, consequence, fix and verification. Distinguish measured defects, platform guidance and design judgment; do not manufacture a numerical UX score.
+
+For a design, deliver a journey map or wireframe, token changes, a component/state table and a verification matrix. For implementation, report changed files and actual checks. Include OS/device or viewport, appearance, text size, locale and assistive interaction where tested; mark remaining device checks unverified. Never claim usability validation without observing users or a relevant study.

package/commands/debate.md

@@ -1,5 +1,5 @@
 ---
-description: Structured debate between the mobile specialists — each agent defends its perspective, rebuts the others, and lead-mobile decides
+description: Structured debate between the mobile specialists — lead-mobile selects the participants, specialists defend and rebut positions, and lead-mobile returns to decide
 argument-hint: "[--rounds N] [--agents a,b,c] [--external] [--providers a,b] <question>"
 allowed-tools: ["Bash(node:*)", "Bash(mkdir:*)", "Agent", "Read", "Write", "Grep", "Glob"]
 ---
@@ -8,7 +8,7 @@ allowed-tools: ["Bash(node:*)", "Bash(mkdir:*)", "Agent", "Read", "Write", "Grep
 
 Arguments received: `$ARGUMENTS`
 
-Use this command for architecture decisions with real trade-offs, not for routine questions: every debate costs several agents across two rounds. If the question has a single answer that can be verified in the code, answer it directly and tell the user why it was not worth a debate.
+Use this command for mobile decisions with real trade-offs, including architecture, UI/UX, accessibility and release readiness. A debate runs several specialists over the configured rounds; avoid it for routine questions. If the question has a single answer that can be verified in the code, answer it directly and tell the user why it was not worth a debate.
 
 ## 1. Parse the arguments
 
@@ -31,9 +31,11 @@ The JSON carries the stack and the `language` for the whole debate: `en` English
 
 If the question mentions files or directories, resolve the paths and read them now: participants receive the content in the briefing, not the path. If it fails, show the error and stop.
 
-## 3. Pick the participants
+## 3. Lead selects the participants
 
-Choose **three** agents whose priorities genuinely conflict on the question. A debate between roles that agree produces no decision.
+Invoke `Agent(subagent_type: "reis-mobile:lead-mobile", model: "opus")` with `phase: selection`, following the **Debate selection** section of `${CLAUDE_PLUGIN_ROOT}/agents/lead-mobile.md`. Pass the question, detected stack and native targets, language, relevant file contents, flags and the complete candidate/model table below. The lead owns participant selection; the command executes the returned plan and does not independently replace participants.
+
+Ask the lead to choose **three** distinct specialists automatically, with relevant perspectives that can expose the question's trade-offs. Disagreement must come from evidence and competing constraints, not a requirement to invent conflict. Every specialist in the plugin is eligible; the lead itself is the selector and moderator, not a debater.
 
 | Agent | Defends | Model |
 |---|---|---|
@@ -55,19 +57,24 @@ Choose **three** agents whose priorities genuinely conflict on the question. A d
 | `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` |
+| `reis-mobile:mobile-ui-ux-designer` | User journeys, visual hierarchy, interaction cost and design consistency | `opus` |
+| `reis-mobile:mobile-accessibility-auditor` | Assistive interaction, readable content, focus and inclusive task completion | `sonnet` |
+| `reis-mobile:mobile-release-engineer` | Artifact provenance, release gates, rollout and production readiness | `opus` |
 
-Pass the `model` from the table on every `Agent` call. It overrides the `model: inherit` the agents declare, and that is what keeps the debate from turning into a monologue: with everyone on the same model, participants inherit the same biases and the same blind spots, and the disagreement stays on the surface of the role. The table pairs model strength with role — `opus` where the question is a long-term trade-off, `sonnet` where it is concrete implementation detail.
+Pass the `model` from the table on each participant's `Agent` call. The lead uses `opus` for both selection and synthesis. Model diversity is a configured perspective check, not proof of independent reasoning or correct conclusions.
 
-Automatic selection must end with **at least two different models** among the participants. If the question leads to three agents on the same model, swap one of them for the most relevant adjacent agent that uses the other model, and tell the user you did so.
+Automatic selection must end with **at least two different models** among the participants. The lead must choose a relevant adjacent specialist using the other model when needed and explain the trade-off. If no relevant mixed-model trio fits the evidence, the lead reports that limitation instead of adding an unrelated role; resolve the scope before launching rounds.
 
 Selection rules:
 
-- 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.
+- The detected stack rules. Match `flutter-*` to Flutter, `android-*` to native Android, `ios-*` to native iOS, `rn-*` to React Native and `kmp-*` Kotlin Multiplatform. For architecture questions, consider the stack's architect, performance and test specialists. For design, accessibility or release questions, prioritize the corresponding cross-stack specialists. All `mobile-*` specialists fit any stack; native specialists may join cross-platform projects when the question implicates their native paths.
+- Select `plugin-native-expert` only for Flutter projects with an implicated native bridge or plugin path.
+- `--agents` overrides automatic membership, but not the models. The lead validates the supplied names (with or without the `reis-mobile:` prefix), requires at least two distinct specialists and preserves valid explicit choices. Unknown names, duplicates or the lead as a participant: explain the error and stop before rounds. An explicit same-model selection is allowed; disclose that limitation without substituting participants.
+- `reis-mobile:lead-mobile` never debates: it selects in step 3 and returns to moderate in step 7. Neither lead call launches participants or external providers.
+
+The lead returns a selection plan containing each participant's exact name, model, assigned question, rationale and evidence scope, plus unresolved constraints. Check the returned names/models against the table, uniqueness, explicit membership and the automatic model mix. If invalid, return the validation errors to the lead for correction before starting; do not silently repair its choices. If Agent delegation is unavailable, report that the debate could not run rather than claiming specialists participated.
 
-Before starting, tell the user in one line the stack, the participants with their models and the number of rounds.
+Before starting, tell the user in one line the stack, the lead-selected participants with their models and the number of rounds.
 
 ## 4. Prepare the folder
 
@@ -75,11 +82,11 @@ Before starting, tell the user in one line the stack, the participants with thei
 mkdir -p ".reis-mobile/debates/<NNN-question-slug>/rounds"
 ```
 
-`NNN` is sequential within `.reis-mobile/debates/`. Write `context.md` in the folder with the question, the stack, the language, the participants, the flags and the context read in step 2.
+`NNN` is sequential within `.reis-mobile/debates/`. Write `context.md` in the folder with the question, the stack, the language, the participants, the flags, the lead's selection plan with its rationale and the context read in step 2.
 
 ## 5. Round 1 — blind positions
 
-Launch the participants **in parallel**, each with `Agent(subagent_type: "<agent>", model: "<model from the table>", run_in_background: true)`, in a single tool block. Nobody sees anyone else's position in this round: that is what keeps the first to answer from anchoring the rest.
+Launch the participants **in parallel**, each with `Agent(subagent_type: "<agent>", model: "<model from the table>", run_in_background: true)`, in a single tool block. Pass each specialist its assigned question and evidence scope from the lead's plan. Instruct every participant to return analysis only, without editing app code or launching subagents. Nobody sees anyone else's position in this round: that is what keeps the first to answer from anchoring the rest.
 
 Each briefing, self-contained:
 
@@ -140,7 +147,7 @@ Rebutting the generic thesis does not count: every rebuttal cites a concrete cla
 
 ## 7. Synthesis
 
-Invoke `reis-mobile:lead-mobile` with all rounds, following the **Debate moderation** section of `${CLAUDE_PLUGIN_ROOT}/agents/lead-mobile.md`. It resolves the disagreements and produces the action plan.
+Invoke `Agent(subagent_type: "reis-mobile:lead-mobile", model: "opus")` again with `phase: synthesis`, the selection plan, original context, all completed rounds and any missing/failed participant statuses, following the **Debate moderation** section of `${CLAUDE_PLUGIN_ROOT}/agents/lead-mobile.md`. It reads the rounds, verifies decisive evidence, resolves the disagreements and delivers the decision with an ordered action plan. This call does not select new participants or start additional rounds.
 
 Before accepting the synthesis, confirm any decisive claim in the code yourself: participants do not verify each other. Write the result to `.reis-mobile/debates/<id>/synthesis.md`.
 

package/core/router/intent-detector.mjs

@@ -1,4 +1,4 @@
-import { AREAS, DEBUG_DOMINATES, INTENTS, INTENT_IDS, STACK_HINTS } from './intents.mjs';
+import { AREAS, DEBUG_DOMINATES, INTENTS, INTENT_IDS, STACK_HINTS, WHOLE_WORDS } from './intents.mjs';
 
 export function normalize(text) {
   return String(text ?? '')
@@ -48,7 +48,8 @@ function matchTerms(text, groups) {
   const counts = new Map();
 
   for (const { id, word } of terms) {
-    const pattern = new RegExp(`(?<![\\p{L}\\p{N}])${escapeRegExp(word)}`, 'gu');
+    const wordEnd = WHOLE_WORDS.has(word) ? '(?![\\p{L}\\p{N}])' : '';
+    const pattern = new RegExp(`(?<![\\p{L}\\p{N}])${escapeRegExp(word)}${wordEnd}`, 'gu');
     for (const match of text.matchAll(pattern)) {
       const start = match.index;
       const end = start + word.length;