reis-mobile 0.10.0 → 0.10.1

package/.claude-plugin/marketplace.json

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

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "reis-mobile",
-  "version": "0.10.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,23 @@ 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

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 26 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, production observability, privacy, networking, authentication, notifications, in-app purchases, migrations, product analytics and device hardware.
+👥 **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,25 +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.10.0
+### v0.10.1
 
 #### 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.
+- `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
 
-- 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.
+- 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
 
-- 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.
+- `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 -->
 
@@ -298,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.
 
@@ -405,7 +402,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 | 21 agents and 26 mobile skills |
+| **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 |
 
@@ -464,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, 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
 
@@ -483,6 +492,7 @@ 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 |
@@ -498,11 +508,11 @@ Every skill starts with `mobile-`. **Topic** skills cover every stack with one r
 | `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 *"configure Firestore rules"* → `mobile-firebase`. Notification requests route to `mobile-notifications`, which links Firebase guidance when FCM is the installed provider.
@@ -537,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 26 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.
 

package/THIRD_PARTY_NOTICES.md

@@ -353,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-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/intents.mjs

@@ -51,6 +51,14 @@ export const INTENTS = {
     'acessibilidade', 'accessibility', 'a11y', 'leitor de tela', 'screen reader',
     'talkback', 'voiceover', 'contraste', 'semantics',
   ],
+  // Keep visual design separate from software architecture and UI test requests.
+  design: [
+    'ui/ux', 'ux/ui', 'ui design', 'ux design', 'design review', 'design de interface',
+    'design de tela', 'design system', 'visual design', 'interface design',
+    'wireframe', 'usabilidade', 'usability', 'hierarquia visual', 'visual hierarchy',
+    'tipografia', 'typography', 'apple hig', 'human interface guidelines',
+    'liquid glass', 'redesign', 'redesenhar',
+  ],
   review: [
     'review', 'revis', 'code review', 'pull request', 'pr', 'prs', 'analis', 'avali', 'audit',
     'code smell',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "reis-mobile",
-  "version": "0.10.0",
+  "version": "0.10.1",
   "description": "AI agents and skills for Flutter, Android, iOS, React Native and Kotlin Multiplatform — a Claude Code and Codex plugin for reviews, debugging, tests, architecture, security and Firebase.",
   "type": "module",
   "license": "MIT",

package/skills/mobile-android/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: mobile-android
 description: Builds native Android apps with the Android team's guides — Jetpack Compose UI, adaptive layouts, edge-to-edge, Compose styles, migrating XML views to Compose, Navigation 3 and predictive back; Android Gradle Plugin 9 upgrades, R8 keep rule analysis, profiling with Android Studio and Perfetto, and the Android CLI; Google Play policy compliance, Play Billing upgrades and the Engage SDK; Credential Manager restore and verified email; CameraX and Media3 Cast; App Functions and the ML Kit GenAI Prompt API; Wear OS, Android TV and display glasses. Use when writing, upgrading or auditing native Android (Kotlin) code for any of these topics, even if the user does not name the library.
-intents: [performance, release, migration, build, dependency]
+intents: [design, performance, release, migration, build, dependency]
 stacks: [android]
 ---
 
@@ -27,3 +27,7 @@ Each topic file lists its guides; open only the ones the task needs.
 
 - Check the AGP, Kotlin, Compose BOM and `compileSdk`/`targetSdk` versions in the build files and version catalog; several guides depend on minimum versions.
 - Several guides prescribe running specific tools or scripts and following steps strictly; run what writes files only with the user's agreement.
+
+## Interface design
+
+For UI/UX reviews, wireframes, design systems and screen redesigns, use [mobile-ui-ux](../mobile-ui-ux/SKILL.md) and its reference for this stack. For Apple targets, also consult its [Apple design workflow](../mobile-ui-ux/references/apple-design.md); validate platform claims against current official guidance and the installed toolkit.

package/skills/mobile-flutter/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: mobile-flutter
 description: Builds Flutter apps with guides for everything specific to Flutter and Dart — layouts, responsive UI, forms, animations, theming, declarative routing with go_router, widget previews and home screen widgets; HTTP, JSON serialization, local databases and caching; plugins, platform channels and native views; isolates and app size; accessibility and localization; Effective Dart, Dart 3 features and pattern matching; and macOS setup. Use when writing or changing Flutter UI, data or native integration code, or when the user asks how to do something in Flutter, even if they do not name the topic.
-intents: [review, performance, accessibility, migration]
+intents: [design, review, performance, accessibility, migration]
 stacks: [flutter]
 ---
 
@@ -28,3 +28,7 @@ Each topic file lists its guides; open only the ones the task needs.
 - Follow the project: its state management, folder structure, lints and packages already in `pubspec.yaml`.
 - Check the Flutter SDK pin (`.fvmrc`, toolchain config or CI) and the installed `flutter --version` before using newer APIs; `pubspec.lock` records resolved packages, not the exact Flutter SDK version.
 - Prefer packages the project already depends on over adding new ones; when adding one, check that it supports every platform the app targets.
+
+## Interface design
+
+For UI/UX reviews, wireframes, design systems and screen redesigns, use [mobile-ui-ux](../mobile-ui-ux/SKILL.md) and its reference for this stack. For Apple targets, also consult its [Apple design workflow](../mobile-ui-ux/references/apple-design.md); validate platform claims against current official guidance and the installed toolkit.

package/skills/mobile-ios/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: mobile-ios
 description: Builds native iOS apps in Swift — SwiftUI and UIKit screens, state and data flow, NavigationStack, lists, forms and accessibility; networking with URLSession and Codable, persistence with SwiftData, Core Data, files and the Keychain; permissions, push notifications, universal links, background tasks, widgets, App Intents and StoreKit 2 purchases; performance with Instruments and MetricKit; and release with signing, TestFlight and App Store Connect. Use when writing or changing native iOS code, adding a platform feature, preparing a build for TestFlight or the App Store, or when the user asks how to do something on iOS, even if they do not name the framework.
-intents: [performance, release, accessibility]
+intents: [design, performance, release, accessibility]
 stacks: [ios]
 ---
 
@@ -23,3 +23,7 @@ Guides for building native iOS apps. Cross-platform topics live in their own ski
 - Check the deployment target (`IPHONEOS_DEPLOYMENT_TARGET`), the Swift language version and the Xcode version: many APIs in these guides need iOS 16 or 17, and Swift 6 changes concurrency checking.
 - Follow the project: SwiftUI or UIKit, its architecture, and dependencies already in `Package.resolved` or `Podfile.lock`.
 - Apple's requirements change every year (minimum SDK for uploads, privacy manifests, review guidelines); check the current ones instead of relying on these guides for dates or version numbers.
+
+## Interface design
+
+For UI/UX reviews, wireframes, design systems and screen redesigns, use [mobile-ui-ux](../mobile-ui-ux/SKILL.md) and its reference for this stack. For Apple targets, also consult its [Apple design workflow](../mobile-ui-ux/references/apple-design.md); validate platform claims against current official guidance and the installed toolkit.

package/skills/mobile-kmp/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: mobile-kmp
 description: Works on Kotlin Multiplatform mobile projects with shared Kotlin source sets and Android/iOS targets. Use for architecture, tests, debugging, reviews, performance, security, accessibility, dependencies and releases when `org.jetbrains.kotlin.multiplatform` is applied; inspect actual targets, `commonMain`/`commonTest`, target source sets, Compose Multiplatform and the iOS framework/host app before giving platform advice.
-intents: [architecture, test, performance, review, debug, security, release, accessibility, migration, dependency, build, deployment]
+intents: [design, architecture, test, performance, review, debug, security, release, accessibility, migration, dependency, build, deployment]
 stacks: [kotlin-multiplatform]
 ---
 
@@ -24,3 +24,7 @@ KMP is a sharing mechanism, not a promise that both apps use the same UI or SDK.
 4. Use the topic skill for the requested work. Use `mobile-android` or `mobile-ios` only for an affected host or target-specific implementation; do not apply native-app instructions blindly to `commonMain`.
 
 The [Kotlin Multiplatform source-set reference](https://kotlinlang.org/docs/multiplatform/multiplatform-dsl-reference.html) defines `commonMain`, `commonTest` and target compilations. Confirm DSL and task names in the project's installed Kotlin and Gradle versions.
+
+## Interface design
+
+For UI/UX reviews, wireframes, design systems and screen redesigns, use [mobile-ui-ux](../mobile-ui-ux/SKILL.md) and its reference for this stack. For Apple targets, also consult its [Apple design workflow](../mobile-ui-ux/references/apple-design.md); validate platform claims against current official guidance and the installed toolkit.

package/skills/mobile-rn/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: mobile-rn
 description: Builds React Native and Expo apps in TypeScript — navigation with React Navigation or Expo Router, lists, forms, styling, gestures and animations with Reanimated, safe areas, accessibility and localization; networking with TanStack Query, response validation, persistence with MMKV, AsyncStorage, SQLite and secure storage; permissions, push notifications, deep links, background tasks, native modules and config plugins; performance with Hermes and the React profiler; and release with EAS Build, EAS Submit and EAS Update or bare Gradle and Xcode builds. Use when writing or changing React Native code, adding a native capability, configuring Expo, preparing a store build or an over-the-air update, or when the user asks how to do something in React Native, even if they do not name the library.
-intents: [performance, release, accessibility]
+intents: [design, performance, release, accessibility]
 stacks: [react-native]
 ---
 
@@ -24,3 +24,7 @@ Guides for building React Native and Expo apps. Cross-platform topics live in th
 - Install libraries with `npx expo install` in Expo projects, so versions match the SDK.
 - Libraries with native code need a new native build (a development build in Expo); they do not work in Expo Go unless the Expo SDK includes them.
 - Native requirements of each platform still apply; see `mobile-ios` and `mobile-android` for store and platform specifics.
+
+## Interface design
+
+For UI/UX reviews, wireframes, design systems and screen redesigns, use [mobile-ui-ux](../mobile-ui-ux/SKILL.md) and its reference for this stack. For Apple targets, also consult its [Apple design workflow](../mobile-ui-ux/references/apple-design.md); validate platform claims against current official guidance and the installed toolkit.

package/skills/mobile-ui-ux/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: mobile-ui-ux
+description: Designs and reviews mobile interfaces across Flutter, Android, iOS, React Native and Kotlin Multiplatform. Use for UI/UX, wireframes, screen redesigns, design systems, visual hierarchy, typography, adaptive layouts, navigation flows, component states and usability reviews of screenshots, Figma artifacts or UI code. Includes an Apple HIG reference workflow for Apple targets while preserving Android conventions.
+intents: [design]
+stacks: ["*"]
+---
+
+# Mobile UI/UX
+
+Turn a product task into a coherent mobile journey and a design that can be implemented and checked. Reuse the app's visual language unless the requested scope calls for a new one.
+
+## Choose references
+
+| Target or task | Read |
+|---|---|
+| Flutter | [Flutter](references/flutter.md) |
+| Native Android | [Android](references/android.md) |
+| Native iOS | [iOS](references/ios.md) |
+| React Native / Expo | [React Native](references/react-native.md) |
+| Kotlin Multiplatform | [Kotlin Multiplatform](references/kotlin-multiplatform.md) |
+| Apple HIG review, Apple-target design, materials or platform-specific behavior | [Apple design](references/apple-design.md) |
+
+Also use [mobile-accessibility](../mobile-accessibility/SKILL.md) for accessibility verification. Open only the references needed for the current target and interaction.
+
+## Ground the work
+
+Read the product brief and real routes, screen components, themes and supported OS/toolkit versions. Identify the task, audience, primary action, constraints and success condition. For a new feature, state assumptions and distinguish proposed components from existing ones. Respect supplied brand assets and designs. Do not invent customer research or conversion results.
+
+Choose the requested mode: review, design or implementation. A review needs evidence and actionable fixes; a design needs a flow, layout and interaction contract; an implementation needs working code and verification. Do not stop at advice when the user asks for changes.
+
+## Specify the flow and visual system
+
+- Map entry, decisions, completion, back and cancel. Name the destination of each action and what happens to unsaved input.
+- Inventory relevant states: initial, loading, populated, empty, validation error, network error, retry, disabled and success. Explain how focus and feedback change between them.
+- Establish hierarchy with real content. Identify the main action, secondary actions and information groups before choosing decoration.
+- Reuse or propose semantic tokens for surfaces, text, actions, status, type roles, spacing, shape and motion. Show where each token is consumed, its light/dark behavior and how it scales. Avoid creating a parallel theme for one screen.
+- Describe what makes the design appropriate to this product. Preserve familiar navigation and input behavior while giving content and brand a deliberate visual treatment.
+- Specify compact and expanded layouts using available space, safe areas and keyboard constraints. Include long content, localization/RTL, large text and reduced motion. Select actual test dimensions from supported targets.
+- Write labels in the product's vocabulary; errors should explain recovery and preserve useful input. Pair gestures with discoverable alternatives.
+
+## Review with evidence
+
+Trace shared components and resolved theme values before claiming a defect. Cite source locations or annotate the supplied artifact. A static image can reveal visual hierarchy but cannot prove hit area, reading order, back behavior or screen-reader output. Measure rendered colors and effective sizes when available; otherwise record what must be checked.
+
+Read the relevant official platform guidance before calling something a platform requirement. Cite the page and section consulted. Check API availability against the project's deployment target and dependency versions. When browsing is unavailable, label current requirements unverified and continue with the evidence available.
+
+Rank issues by blocked tasks and recovery cost, then recurring friction and visual polish. Separate platform guidance, confirmed defects and aesthetic judgment. Do not treat every stylistic preference as a violation or apply iOS conventions to Android-only UI.
+
+## Deliver and verify
+
+Provide a compact journey/wireframe and a table of component, state, action, destination/feedback and implementation owner. For changes, list reused/new tokens and the affected files. Verify the primary journey plus failure/retry, back/cancel and keyboard input on supported targets. Inspect light/dark, large text and the relevant assistive technology. Use existing screenshot or UI tests when they cover the change; add regression tests for behavior rather than mirroring token constants.
+
+State exactly what ran, what was observed and which device checks remain. A source-only review is not a usability study or accessibility certification.

package/skills/mobile-ui-ux/references/android.md

@@ -0,0 +1,11 @@
+# Android interface design
+
+Start with the app's existing Compose or Views components and theme. Use [Android UI guides](../../mobile-android/references/ui.md) and current [Android mobile design guidance](https://developer.android.com/design/ui/mobile).
+
+- Use the app's Material theme roles and component defaults as the baseline. Document brand overrides and check semantic colors in both appearances.
+- Select navigation and pane structure from available window space and the user's task. Preserve back behavior and navigation state when the window changes.
+- Include system bars, display cutouts and keyboard insets in the layout contract. Test resizing and long content rather than assuming a fixed phone canvas.
+- Specify form focus, keyboard actions, validation recovery and state restoration. Keep transient messages distinct from persistent errors that need action.
+- Check text scaling, effective touch regions and TalkBack semantics using the actual rendered components; load the [Android accessibility reference](../../mobile-accessibility/references/android.md).
+
+Use preview variants for fast visual feedback, then verify the journey on the supported device/window sizes. Apple references may inform a comparison, but do not make iOS bars or gestures Android requirements.

package/skills/mobile-ui-ux/references/apple-design.md

@@ -0,0 +1,32 @@
+# Apple design reference workflow
+
+## External material and provenance
+
+The user-requested [apple-design-skill by dickwu](https://github.com/dickwu/apple-design-skill) is an optional external reading source for Apple-oriented interface reviews. Inspected revision: `ff4ebddf0488598723a82bfdce1afb04de0b1c44` (2026-11-04). Its [skill entry point at that revision](https://github.com/dickwu/apple-design-skill/blob/ff4ebddf0488598723a82bfdce1afb04de0b1c44/SKILL.md) links its topic references.
+
+That revision has no LICENSE file or explicit redistribution license; its README attributes the reproduced HIG text to Apple. This plugin does not vendor its instructions, scripts or HIG snapshots, and does not assign them this repository's MIT license. The workflow here is original plugin guidance with external links. See [third-party notices](../../../THIRD_PARTY_NOTICES.md).
+
+Read the external skill when the task calls for its Apple-focused perspective, then open only the topics relevant to the actual screen. Treat it as secondary reference material: check claims, numeric thresholds, hardware assumptions and API availability against current official documentation and the project's supported targets. Do not execute its download script or install its tool-specific configuration as part of a review.
+
+## Choose official sources by decision
+
+| Decision | Official starting point |
+|---|---|
+| Platform conventions and current topic index | [Apple HIG](https://developer.apple.com/design/human-interface-guidelines) |
+| Adaptive organization, available space and positioning | [Layout](https://developer.apple.com/design/human-interface-guidelines/layout) |
+| Text roles and scaling | [Typography](https://developer.apple.com/design/human-interface-guidelines/typography) |
+| Semantic palette and appearance | [Color](https://developer.apple.com/design/human-interface-guidelines/color), [Dark mode](https://developer.apple.com/design/human-interface-guidelines/dark-mode) |
+| Assistive interactions and accessibility settings | [Accessibility](https://developer.apple.com/design/human-interface-guidelines/accessibility) |
+| Navigation destinations and modal tasks | [Tab bars](https://developer.apple.com/design/human-interface-guidelines/tab-bars), [Sheets](https://developer.apple.com/design/human-interface-guidelines/sheets) |
+| Translucency and system materials | [Materials](https://developer.apple.com/design/human-interface-guidelines/materials) |
+| Form behavior | [Entering data](https://developer.apple.com/design/human-interface-guidelines/entering-data) |
+
+Read the page before citing a requirement; record the heading and URL. If a page has moved, find it through the official index. If unavailable, mark the claim unverified rather than treating a cached third-party statement as current Apple policy.
+
+## Apply to this app
+
+Identify the Apple target and actual renderer before choosing components. In Flutter, React Native and shared Compose, separate the desired behavior from the framework implementation and verify both. Keep Android-specific decisions in the Android reference.
+
+For each proposed change, connect the user task to a real screen/control, the consulted guidance, the intended behavior and a concrete verification step. Preserve brand identity where it does not interfere with comprehension and task completion. For materials, check readability with actual content behind the surface and relevant accessibility settings, and specify a fallback supported by the deployment target.
+
+When reviewing a static artifact, report visual observations separately from runtime questions. When reviewing source, follow wrappers and resolved tokens. Never present estimated sizes, unmeasured contrast or untested assistive interactions as verified failures.

package/skills/mobile-ui-ux/references/flutter.md

@@ -0,0 +1,11 @@
+# Flutter interface design
+
+Inspect the existing widget tree, routing package, ThemeData/CupertinoTheme and supported targets. Reuse [Flutter UI guides](../../mobile-flutter/references/ui.md) for implementation.
+
+- Resolve colors and text roles through the app theme, including custom theme extensions already present. Do not replace scalable text with fixed-height containers.
+- Design from layout constraints; inspect SafeArea, scroll ownership and keyboard insets. Check narrow widths, large text and long translated labels together.
+- Choose Material or Cupertino controls to match the target and app contract. An adaptive constructor does not guarantee every gesture, sheet or navigation convention is native.
+- Specify selected, pressed, disabled, loading and validation states in shared widgets. Keep action labels and semantic roles available when icons or motion carry visual meaning.
+- On iOS, consult [Apple design](apple-design.md); on Android, use [Android design guidance](android.md). Verify each target rather than copying Apple's styling into both.
+
+Use existing widget/golden coverage for changed components, then exercise the complete flow on the intended target. A golden screenshot does not prove focus or gesture behavior.

package/skills/mobile-ui-ux/references/ios.md

@@ -0,0 +1,11 @@
+# iOS interface design
+
+Read [Apple design](apple-design.md) for the source workflow and [iOS UI and navigation](../../mobile-ios/references/ui-navigation.md) for implementation. Identify SwiftUI versus UIKit, deployment target, supported devices and existing component wrappers.
+
+- Use semantic system text and color roles through the app's theme. Check Dynamic Type, dark appearance and content expansion before accepting a fixed frame.
+- Specify navigation destinations, selection, back behavior and sheet dismissal using the existing navigation model. Preserve work when a modal is cancelled or a size change rearranges panes.
+- Test safe areas, keyboard presentation, compact/expanded layouts and multiline controls. Distinguish a visual icon's dimensions from the interactive area.
+- Prefer supported system controls for platform-specific behavior. Verify availability and fallback before proposing newer materials or APIs; a custom blur is not proof of native material behavior.
+- Keep focus and spoken feedback in the interaction specification; consult [iOS accessibility](../../mobile-accessibility/references/ios.md).
+
+Preview light/dark and large-text variants with realistic content. Confirm interactions on the supported runtime. Do not infer App Review acceptance from a visual inspection.

package/skills/mobile-ui-ux/references/kotlin-multiplatform.md

@@ -0,0 +1,11 @@
+# Kotlin Multiplatform interface design
+
+Determine whether UI is shared Compose Multiplatform or separate Android/iOS hosts. Read [shared Compose UI](../../mobile-kmp/references/compose-ui.md) and inspect the actual renderer for each screen.
+
+- Share the journey, content states and semantic token meanings where appropriate. Map them to each host's controls, navigation and accessibility behavior.
+- For shared Compose, verify the installed version's target support; do not assume Material controls acquire UIKit behavior on iOS.
+- For native hosts, use [Android](android.md) and [iOS](ios.md) independently. Maintain consistent task completion without forcing identical layouts.
+- Specify how state survives pane changes, rotation, navigation and cancellation. Locate the shared state owner and the host responsible for focus, keyboard and safe areas.
+- Check typography, localized text, appearance and assistive interaction on each target. An Android preview cannot validate the iOS host.
+
+For Apple-target decisions consult [Apple design](apple-design.md). Deliver a table of shared decisions and target-specific components so implementation ownership is clear.

package/skills/mobile-ui-ux/references/react-native.md

@@ -0,0 +1,11 @@
+# React Native interface design
+
+Inspect the installed React Native/Expo versions, navigator and component library. Use [React Native UI and navigation](../../mobile-rn/references/ui-navigation.md) for implementation.
+
+- Reuse the theme and token layer; map system appearance into semantic surface, text and action roles. Keep font scaling enabled and test multiline content.
+- Identify native-stack versus JavaScript-rendered headers, sheets and tabs before promising native behavior. Check back/swipe behavior and route state on each OS.
+- Specify safe-area ownership, keyboard avoidance and scroll behavior together to prevent duplicate insets or hidden primary actions.
+- Preserve accessible roles, labels, states and focus across custom Pressable wrappers. Verify disabled and loading behavior rather than relying on opacity alone.
+- Consult [Apple design](apple-design.md) for iOS and [Android](android.md) for Android. Share semantic tokens while retaining target-specific interaction details.
+
+Verify the complete flow on both intended runtimes, including large text, dark appearance and keyboard-visible forms. JavaScript component tests alone do not verify native transitions or screen-reader behavior.