reis-mobile 0.3.5

package/skills/dart-resolve-package-conflicts/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: dart-resolve-package-conflicts
+description: Workflow for fixing package version conflicts. Use this when `pub get` fails due to incompatible package versions.
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Fri, 24 Apr 2026 15:11:14 GMT
+intents: [debug, dependency]
+stacks: [flutter]
+source: https://github.com/dart-lang/skills
+license: BSD-3-Clause
+---
+# Managing Dart Dependencies
+
+## Contents
+- [Core Concepts](#core-concepts)
+- [Version Constraints](#version-constraints)
+- [Workflow: Auditing Dependencies](#workflow-auditing-dependencies)
+- [Workflow: Upgrading Dependencies](#workflow-upgrading-dependencies)
+- [Workflow: Resolving Version Conflicts](#workflow-resolving-version-conflicts)
+- [Examples](#examples)
+
+## Core Concepts
+
+Dart enforces a strict single-version rule for dependencies: a project and all its transitive dependencies must resolve to a single, shared version of any given package. This prevents runtime type mismatches but introduces the risk of "version lock."
+
+To mitigate version lock, Dart relies on version constraints rather than pinned versions in the `pubspec.yaml`. The `pubspec.lock` file maintains the exact resolved versions for reproducible builds.
+
+Understand the output columns of `dart pub outdated`:
+*   **Current:** The version currently recorded in `pubspec.lock`.
+*   **Upgradable:** The latest version allowed by the constraints in `pubspec.yaml`. `dart pub upgrade` resolves to this.
+*   **Resolvable:** The absolute latest version that can be resolved when factoring in all other dependencies in the project.
+*   **Latest:** The latest published version of the package (excluding prereleases).
+
+## Version Constraints
+
+*   **Use Caret Syntax:** Always use caret syntax (e.g., `^1.2.3`) for dependencies in `pubspec.yaml`. This allows `pub` to select newer, non-breaking versions (up to, but not including, the next major version) during resolution.
+*   **Tighten Dev Dependencies:** Set the lower bound of `dev_dependencies` to the exact version currently used. This reduces resolution complexity and prevents older, incompatible dev tools from being selected.
+*   **Enforce Lockfiles in CI:** Use `dart pub get --enforce-lockfile` in CI/CD pipelines to ensure the exact versions tested locally are used in production.
+
+## Workflow: Auditing Dependencies
+
+Run this workflow periodically to identify stale packages that may impact stability or performance.
+
+**Task Progress:**
+- [ ] Run `dart pub outdated`.
+- [ ] Review the **Upgradable** column to identify packages that can be updated without modifying `pubspec.yaml`.
+- [ ] Review the **Resolvable** column to identify packages that require constraint modifications in `pubspec.yaml` to update.
+- [ ] Identify any packages marked as retracted or discontinued.
+
+## Workflow: Upgrading Dependencies
+
+Use conditional logic based on the audit results to upgrade dependencies.
+
+**Task Progress:**
+- [ ] **If updating to "Upgradable" versions:**
+  - [ ] Run `dart pub upgrade`.
+  - [ ] Run `dart pub upgrade --tighten` to automatically update the lower bounds in `pubspec.yaml` to match the newly resolved versions.
+- [ ] **If updating to "Resolvable" versions (Major updates):**
+  - [ ] Manually edit `pubspec.yaml` to bump the version constraint to match the "Resolvable" column (e.g., change `^0.11.0` to `^0.12.1`).
+  - [ ] Run `dart pub upgrade` to resolve the new constraints and update `pubspec.lock`.
+- [ ] **Feedback Loop:**
+  - [ ] Run `dart analyze` -> review errors -> fix breaking API changes.
+  - [ ] Run `dart test` -> review failures -> fix regressions.
+
+## Workflow: Resolving Version Conflicts
+
+When `pub` cannot find a set of concrete versions that satisfy all constraints, or when dealing with a retracted package version, manipulate the lockfile surgically.
+
+**NEVER** delete the entire `pubspec.lock` file and run `dart pub get`. This causes uncontrolled upgrades across the entire dependency graph.
+
+**Task Progress:**
+- [ ] Open `pubspec.lock`.
+- [ ] Locate the specific YAML block for the conflicting or retracted package.
+- [ ] Delete ONLY that package's entry from the lockfile.
+- [ ] Run `dart pub get` to fetch the newest compatible, non-retracted version for that specific package.
+- [ ] **Feedback Loop:**
+  - [ ] Run `dart pub deps` -> verify the dependency graph resolves correctly.
+  - [ ] If resolution fails, identify the transitive dependency causing the lock, update its constraint in `pubspec.yaml`, and retry.
+
+## Examples
+
+### Tightening Constraints
+When `dart pub outdated` shows a package is resolvable to a higher minor/patch version, use the `--tighten` flag to update the `pubspec.yaml` automatically.
+
+**Input (`pubspec.yaml`):**
+```yaml
+dependencies:
+  http: ^0.13.0
+```
+
+**Command:**
+```bash
+dart pub upgrade --tighten http
+```
+
+**Output (`pubspec.yaml`):**
+```yaml
+dependencies:
+  http: ^0.13.5
+```
+
+### Surgical Lockfile Removal
+If `package_a` is retracted or locked in a conflict, remove only its block from `pubspec.lock`.
+
+**Before (`pubspec.lock`):**
+```yaml
+packages:
+  package_a:
+    dependency: "direct main"
+    description:
+      name: package_a
+      url: "https://pub.dev"
+    source: hosted
+    version: "1.0.0" # Retracted version
+  package_b:
+    dependency: "direct main"
+    # ...
+```
+
+**Action:** Delete the `package_a` block entirely. Leave `package_b` untouched. Run `dart pub get`.

package/skills/dart-run-static-analysis/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: dart-run-static-analysis
+description: Execute `dart analyze` to identify warnings and errors, and use `dart fix --apply` to automatically resolve mechanical lint issues. Use during development to ensure code quality and before committing changes.
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Fri, 24 Apr 2026 15:09:34 GMT
+intents: [review]
+stacks: [flutter]
+source: https://github.com/dart-lang/skills
+license: BSD-3-Clause
+---
+# Analyzing and Fixing Dart Code
+
+## Contents
+- [Analysis Configuration](#analysis-configuration)
+- [Diagnostic Suppression](#diagnostic-suppression)
+- [Workflow: Executing Static Analysis](#workflow-executing-static-analysis)
+- [Workflow: Applying Automated Fixes](#workflow-applying-automated-fixes)
+- [Examples](#examples)
+
+## Analysis Configuration
+
+Configure the Dart analyzer using the `analysis_options.yaml` file located at the package root.
+
+- **Base Configuration:** Always include a standard rule set (e.g., `package:lints/recommended.yaml` or `package:flutter_lints/flutter.yaml`) using the `include:` directive.
+- **Strict Type Checks:** Enable strict type checks under the `analyzer: language:` node to prevent implicit downcasts and dynamic inferences. Set `strict-casts: true`, `strict-inference: true`, and `strict-raw-types: true`.
+- **Linter Rules:** Explicitly enable or disable specific rules under the `linter: rules:` node. Use a key-value map (`rule_name: true/false`) when overriding included rules, or a list (`- rule_name`) when defining a fresh set. Do not mix list and map syntax in the same `rules` block.
+- **Formatter Configuration:** Configure `dart format` behavior under the `formatter:` node. Set `page_width` (default 80) and `trailing_commas` (`automate` or `preserve`).
+- **Analyzer Plugins:** Enable custom diagnostics by adding plugins under the `analyzer: plugins:` node. Ensure the plugin package is added as a `dev_dependency` in `pubspec.yaml`.
+
+## Diagnostic Suppression
+
+When a diagnostic (lint or warning) yields a false positive or applies to generated code, suppress it explicitly.
+
+- **File-level Exclusion:** Use the `analyzer: exclude:` node in `analysis_options.yaml` to exclude entire files or directories (e.g., `**/*.g.dart`) using glob patterns.
+- **File-level Suppression:** Add `// ignore_for_file: <diagnostic_code>` at the top of a Dart file to suppress specific diagnostics for the entire file. Use `// ignore_for_file: type=lint` to suppress all linter rules.
+- **Line-level Suppression:** Add `// ignore: <diagnostic_code>` on the line directly above the offending code, or appended to the end of the offending line.
+- **Pubspec Suppression:** Add `# ignore: <diagnostic_code>` above the offending line in `pubspec.yaml` files (e.g., `# ignore: sort_pub_dependencies`).
+- **Plugin Diagnostics:** Prefix the diagnostic code with the plugin name when suppressing plugin-specific issues (e.g., `// ignore: some_plugin/some_code`).
+
+## Workflow: Executing Static Analysis
+
+Use this workflow to identify type-related bugs, style violations, and potential runtime errors.
+
+**Task Progress:**
+- [ ] 1. Verify `analysis_options.yaml` exists at the project root.
+- [ ] 2. Run the analyzer using the `analyze_files` MCP tool (if available) or the CLI command `dart analyze <target_directory>`.
+- [ ] 3. Review the diagnostic output.
+- [ ] 4. If info-level issues must be treated as failures, append the `--fatal-infos` flag.
+- [ ] 5. Resolve reported errors manually or proceed to the Automated Fixes workflow.
+
+## Workflow: Applying Automated Fixes
+
+Use this workflow to resolve outdated API usages, apply quick fixes, and migrate code (e.g., Dart 3 migrations).
+
+**Task Progress:**
+- [ ] 1. Execute a dry run to preview proposed changes using the `dart_fix` MCP tool or CLI command `dart fix --dry-run`.
+- [ ] 2. Review the proposed fixes to ensure they align with the intended architecture.
+- [ ] 3. If additional fixes are required, verify that the corresponding linter rules are enabled in `analysis_options.yaml`.
+- [ ] 4. Apply the fixes using the `dart_fix` MCP tool or CLI command `dart fix --apply`.
+- [ ] 5. Format the modified code using the `dart_format` MCP tool or CLI command `dart format .`.
+- [ ] 6. Run the static analysis workflow to verify all diagnostics are resolved.
+
+## Examples
+
+### Comprehensive `analysis_options.yaml`
+
+```yaml
+include: package:flutter_lints/recommended.yaml
+
+analyzer:
+  exclude:
+    - "**/*.g.dart"
+    - "lib/generated/**"
+  language:
+    strict-casts: true
+    strict-inference: true
+    strict-raw-types: true
+  errors:
+    todo: ignore
+    invalid_assignment: warning
+    missing_return: error
+
+linter:
+  rules:
+    avoid_shadowing_type_parameters: false
+    await_only_futures: true
+    use_super_parameters: true
+
+formatter:
+  page_width: 100
+  trailing_commas: preserve
+```
+
+### Inline Diagnostic Suppression
+
+```dart
+// Suppress for the entire file
+// ignore_for_file: unused_local_variable, dead_code
+
+void processData() {
+  // Suppress for a specific line
+  // ignore: invalid_assignment
+  int x = '';
+  
+  const y = 10; // ignore: constant_identifier_names
+}
+```

package/skills/dart-use-pattern-matching/SKILL.md

@@ -0,0 +1,240 @@
+---
+name: dart-use-pattern-matching
+description: >-
+  Applies Dart 3 pattern matching, switch expressions, and destructuring
+  idiomatically to validate data schemas, handle algebraic data types, and
+  decompose control flow. Use when refactoring complex if-else chains,
+  parsing polymorphic JSON or API responses, destructuring Records or Maps, or
+  enforcing exhaustiveness on sealed classes. Don't use for simple boolean
+  conditions, single-variable type promotion (use `is`), or basic collection
+  filtering.
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Sun, 06 Sep 2026 06:43:00 GMT
+routing: manual
+stacks: [flutter]
+source: https://github.com/dart-lang/skills
+license: BSD-3-Clause
+---
+# Implementing Dart Patterns
+
+## Contents
+- [Pattern Selection Strategy](#pattern-selection-strategy)
+- [Switch Statements vs. Expressions](#switch-statements-vs-expressions)
+- [Core Pattern Implementations](#core-pattern-implementations)
+- [Pragmatic Balance & Anti-Patterns](#pragmatic-balance--anti-patterns)
+- [Workflows](#workflows)
+- [Examples](#examples)
+
+## Pattern Selection Strategy
+
+Apply specific pattern types based on the data structure and desired outcome. Follow these conditional guidelines:
+
+*   **If validating and extracting from deserialized data (e.g., JSON):** Use Map, List, and Object patterns to validate schema structure and destructure properties in a single step.
+*   **If handling polymorphic payloads or responses:** Use `switch` expressions over map discriminant keys to deserialize into `sealed` class hierarchies.
+*   **If handling multiple return values:** Use Record patterns to destructure fields directly into local variables.
+*   **If executing type-specific behavior (Algebraic Data Types):** Use Object patterns combined with `sealed` classes to ensure exhaustiveness.
+*   **If matching numeric ranges or conditions:** Use Relational (`>=`, `<=`) and Logical-and (`&&`) patterns within switch arms.
+*   **If multiple cases share logic:** Use Logical-or (`||`) patterns to share a single case body or guard clause.
+*   **If ignoring specific values:** Use the Wildcard pattern (`_`) or a non-matching Rest element (`...`) in collections.
+
+## Switch Statements vs. Expressions
+
+Select the appropriate switch construct based on the execution context:
+
+*   **If producing a value:** Use a **switch expression**.
+    *   Syntax: `switch (value) { pattern => expression, }`
+    *   Rule: Each case must be a single expression. No implicit fallthrough. Must be exhaustive.
+*   **If executing statements or side effects:** Use a **switch statement**.
+    *   Syntax: `switch (value) { case pattern: statements; }`
+    *   Rule: Empty cases fall through to the next case. Non-empty cases implicitly break (no `break` keyword required).
+
+## Core Pattern Implementations
+
+Implement patterns using the following syntax and rules:
+
+*   **Logical-or (`||`):** `pattern1 || pattern2`. Both branches must define the exact same set of variables.
+*   **Logical-and (`&&`):** `pattern1 && pattern2`. Branches must *not* define overlapping variables.
+*   **Relational:** `==`, `!=`, `<`, `>`, `<=`, `>=` followed by a constant expression.
+*   **Cast (`as`):** `pattern as Type`. Throws if the value does not match the type. Use to forcibly assert types during destructuring.
+*   **Null-check (`?`):** `pattern?`. Fails the match if the value is null. Binds the variable to the non-nullable base type.
+*   **Null-assert (`!`):** `pattern!`. Throws if the value is null.
+*   **Variable:** `var name` or `Type name`. Binds the matched value to a new local variable.
+*   **Wildcard (`_`):** Matches any value and discards it.
+*   **List:** `[pattern1, pattern2]`. Matches lists of exact length unless a Rest element (`...` or `...var rest`) is used.
+*   **Map:** `{"key": pattern}`. Matches maps containing the specified keys. Ignores unmatched keys.
+*   **Record:** `(pattern1, named: pattern2)`. Matches records of the exact shape. Use `:var name` to infer the getter name.
+*   **Object:** `ClassName(field: pattern)`. Matches instances of `ClassName`. Use `:var field` to infer the getter name.
+
+## Pragmatic Balance & Anti-Patterns
+
+Pattern matching and switch expressions should simplify code, not add syntactic overhead. Observe the following boundaries:
+
+### 1. Prefer `is` Type Promotion over `if-case` for Single Promotable Variables
+When checking or promoting a single variable, use standard `is` checks instead of `if-case` patterns that introduce shadow aliases.
+
+*   **Prefer:**
+    ```dart
+    // ✅ Promotes `key` directly in-place without extra variables
+    for (final MapEntry(:key, :value) in map.entries) {
+      if (key is String && value != null) {
+        process(key, value);
+      }
+    }
+    ```
+*   **Avoid:**
+    ```dart
+    // ❌ Anti-pattern: Introduces unnecessary alias variable `k`
+    for (final MapEntry(:key, :value) in map.entries) {
+      if (key case final String k when value != null) {
+        process(k, value);
+      }
+    }
+    ```
+
+### 2. Consolidate Nullable Types in Switch Arms
+When mapping or returning values where both `null` and a type `T` are valid and handled identically, match the nullable type `T?` directly rather than creating redundant `null` arms.
+
+*   **Prefer:**
+    ```dart
+    // ✅ Clean nullable pattern match
+    switch (value) {
+      final String? s => s,
+      _ => throw FormatException('Invalid value: $value'),
+    }
+    ```
+*   **Avoid:**
+    ```dart
+    // ❌ Redundant separate null arm
+    switch (value) {
+      final String s => s,
+      null => null,
+      _ => throw FormatException('Invalid value: $value'),
+    }
+    ```
+
+### 3. Preserve Fast-Fail Validation (Do Not Silently Drop Data)
+Do not use `if-case` in loops or deserialization to filter elements if malformed data should trigger an error or diagnostic warning.
+
+*   **Prefer:**
+    ```dart
+    // ✅ Fast-fail with explicit diagnostic error
+    for (final raw in rawTasks) {
+      if (raw is! Map<String, dynamic>) {
+        throw FormatException('Expected Map item, got ${raw.runtimeType}: $raw');
+      }
+      _applyTask(raw);
+    }
+    ```
+*   **Avoid:**
+    ```dart
+    // ❌ Silently ignores malformed items
+    for (final raw in rawTasks) {
+      if (raw case final Map<String, dynamic> taskMap) {
+        _applyTask(taskMap);
+      }
+    }
+    ```
+
+### 4. Avoid Single-Case or Boolean Switches
+*   Use `if (x is T)` instead of a `switch` statement with only 1 case and `default: break;`.
+*   Use standard conditional ternary operators (`condition ? a : b`) instead of `switch (condition) { true => a, false => b }`.
+
+### 5. Avoid Gratuitous Object Destructuring
+Use standard property access (`user.name`) rather than object pattern destructuring (`final User(:name) = user;`) when reading a single property on a known non-null instance.
+
+### 6. Avoid `if-case` for Standalone Scalar Comparisons
+Use standard boolean operators (`if (code >= 200 && code < 300)`) instead of `if (code case >= 200 && < 300)` for standalone conditions. Reserve relational patterns for multi-arm `switch` tables.
+
+## Workflows
+
+### Task Progress: Implementing Pattern Matching
+Copy this checklist to track progress when implementing complex pattern matching logic:
+
+- [ ] Identify the data structure being evaluated (JSON, Record, Class, Enum).
+- [ ] Select the appropriate switch construct (Expression for values, Statement for side-effects).
+- [ ] Define the required patterns (Object, Map, List, Record).
+- [ ] Extract required data using Variable patterns (`var x`, `:var y`).
+- [ ] Apply Guard clauses (`when condition`) for logic that cannot be expressed via patterns.
+- [ ] Handle unmatched cases using a Wildcard (`_`) or `default` clause (if not using a sealed class).
+- [ ] Run static analyzer for exhaustiveness and dead code (`dart analyze`).
+- [ ] Verify runtime Map/JSON pattern behavior on omitted keys (`containsKey` semantics) vs explicit `null` values.
+
+### Feedback Loop 1: Exhaustiveness Checking (Static Verification)
+When switching over `sealed` classes or enums, ensure all subtypes are handled at compile time:
+
+1. **Run analyzer:** Execute `dart analyze`.
+2. **Review errors:** Look for "The type 'X' is not exhaustively matched by the switch cases" or unreachable pattern arm warnings.
+3. **Fix:** Add the missing Object patterns for unhandled subtypes, or add an explicit wildcard (`_`) arm if a default fallback or error is acceptable.
+
+### Feedback Loop 2: Runtime Map & JSON Pattern Verification
+Because `dart analyze` cannot statically verify dynamic `Map<String, dynamic>` keys, validate runtime pattern semantics explicitly:
+
+1. **Omitted Keys vs. Explicit `null`**: A map pattern `{'key': String? val}` checks `map.containsKey('key')`. If `'key'` is omitted from the JSON payload, the pattern fails to match at runtime even though `String?` is nullable. Extract optional keys from the validated map directly (`map['key'] as String?`).
+2. **Fast-Fail Fallback**: Ensure unmatched or malformed map structures hit an explicit `_ => throw FormatException(...)` arm rather than silently failing an `if-case` check.
+
+## Examples
+
+### Polymorphic JSON Deserialization (Discriminated Unions)
+Use Map patterns with switch expressions to validate tagged JSON payloads and
+construct `sealed` class hierarchies. See
+[examples/json_patterns.dart](examples/json_patterns.dart) for an executable
+implementation demonstrating tagged `ApiResponse` parsing into `SuccessResponse`
+and `ErrorResponse`.
+
+### Nested JSON Validation and Optional Fields
+Use nested Map and List patterns to validate required schema structure and
+extract collections in a single step. See
+[examples/json_patterns.dart](examples/json_patterns.dart) for an executable
+implementation of `processUserPayload`.
+
+Map patterns check for key existence (`containsKey`). If an optional JSON key
+might be omitted entirely from the payload (rather than explicitly passed as
+`'key': null`), destructure required keys via the pattern and extract optional
+fields directly from the matched submap.
+
+### Algebraic Data Types (Sealed Classes)
+Use Object patterns with switch expressions to handle family types exhaustively.
+
+```dart
+sealed class Shape {}
+
+class Square implements Shape {
+  final double length;
+  Square(this.length);
+}
+
+class Circle implements Shape {
+  final double radius;
+  Circle(this.radius);
+}
+
+// Switch expression guarantees exhaustiveness due to `sealed` modifier.
+double calculateArea(Shape shape) => switch (shape) {
+  Square(length: var l) => l * l,
+  Circle(:var radius)   => math.pi * radius * radius,
+};
+```
+
+### Variable Swapping and Destructuring
+Use variable assignment patterns to swap values or extract record fields without temporary variables.
+
+```dart
+var (a, b) = ('left', 'right');
+(b, a) = (a, b); // Swap values
+
+// Destructuring a function return
+var (name, age) = getUserInfo();
+```
+
+### Guard Clauses and Logical-or
+Use `when` to evaluate arbitrary conditions after a pattern matches.
+
+```dart
+switch (shape) {
+  case Square(length: var s) || Circle(radius: var s) when s > 0:
+    print('Valid positive shape with dimension $s');
+  case Square() || Circle():
+    print('Zero or negative dimension shape');
+}
+```

package/skills/dart-use-pattern-matching/examples/json_patterns.dart

@@ -0,0 +1,85 @@
+// Copyright (c) 2025, the Dart project authors. Please see the AUTHORS file
+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+
+/// Examples of Dart pattern matching for JSON handling:
+/// - Polymorphic JSON deserialization (discriminated unions)
+/// - Nested JSON validation with optional and omitted keys
+library;
+
+/// Represents an API response in a sealed hierarchy.
+sealed class ApiResponse {}
+
+/// Successful API response carrying data.
+class SuccessResponse implements ApiResponse {
+  final Map<String, dynamic> data;
+  SuccessResponse(this.data);
+}
+
+/// Error API response carrying an error message and code.
+class ErrorResponse implements ApiResponse {
+  final String message;
+  final int code;
+  ErrorResponse(this.message, this.code);
+}
+
+/// Parses a raw JSON map into an [ApiResponse] subtype.
+ApiResponse parseApiResponse(Map<String, dynamic> json) => switch (json) {
+  {'status': 'ok', 'data': Map<String, dynamic> data} => SuccessResponse(data),
+  {'status': 'error', 'message': String msg, 'code': int code} => ErrorResponse(
+    msg,
+    code,
+  ),
+  _ => throw FormatException('Invalid or unrecognized API response: $json'),
+};
+
+/// Validates a nested user payload with both required schema and optional keys.
+void processUserPayload(Map<String, dynamic> json) {
+  if (json case {
+    'id': String id,
+    'profile':
+        {'name': String name, 'email': String email} &&
+        final Map<String, dynamic> profile,
+    'tags': [
+      String primaryTag,
+      ...,
+    ], // Matches at least 1 element, ignores rest
+  }) {
+    // Read optional/omitted fields directly from the validated submap.
+    // Map patterns check for key existence (containsKey), so an omitted key
+    // fails matching even if typed as String?.
+    final avatarUrl = profile['avatarUrl'] as String?;
+    print(
+      'User $name ($id, $email, avatar: $avatarUrl) - Primary tag: $primaryTag',
+    );
+  } else {
+    throw FormatException('Malformed user payload structure: $json');
+  }
+}
+
+void main() {
+  // Test polymorphic deserialization
+  final success = parseApiResponse({
+    'status': 'ok',
+    'data': {'userId': '123'},
+  });
+  print('Parsed success: $success');
+
+  final error = parseApiResponse({
+    'status': 'error',
+    'message': 'Not found',
+    'code': 404,
+  });
+  print('Parsed error: $error');
+
+  // Test nested validation
+  processUserPayload({
+    'id': 'u100',
+    'profile': {
+      'name': 'Alice',
+      'email': 'alice@example.com',
+      'avatarUrl': 'https://example.com/avatar.png',
+    },
+    'tags': ['admin', 'staff'],
+  });
+}

package/skills/detect-mobile-stack/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: detect-mobile-stack
+description: Detects the mobile stack of the current project (Flutter, Android, iOS, React Native, Kotlin Multiplatform), its languages and target platforms, using the reis-mobile detector. Use when you need to know which mobile stack a project uses before reviewing, debugging or changing it, or when the user asks "what stack is this project?".
+routing: manual
+stacks: ["*"]
+---
+
+# Detect Mobile Stack
+
+Use the reis-mobile deterministic detector instead of guessing from the folder structure.
+
+## How to run
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/bin/reis-mobile.mjs" detect --json --dir "<project directory>"
+```
+
+Result fields:
+
+| Field | Meaning |
+|---|---|
+| `stack` | `flutter`, `react-native`, `kotlin-multiplatform`, `android`, `ios` or `unknown` |
+| `variant` | `plugin` (Flutter), `expo` (React Native) or `null` |
+| `languages` | Languages found, the main one first (includes native code in cross-platform apps) |
+| `platforms` | Target platforms (`android`, `ios`, `web`, `macos`, `desktop`...) |
+| `evidence` | Files that justify the detection |
+| `candidates` | Every stack that matched, in priority order |
+
+## Interpretation
+
+- Cross-platform stacks take priority: a Flutter app contains `android/` and `ios/`, but the stack is `flutter`.
+- `unknown` means there is no mobile project at the given root. In monorepos, run it again with `--dir` pointing at the app.
+- More than one item in `candidates` indicates a hybrid project (for example, KMP with an Android module). Consider both stacks when loading skills.