reis-mobile 0.3.5

package/skills/mockito/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: mockito
+description: Uses the Mockito package for mocking in Flutter/Dart tests. Use when generating mocks, stubbing methods, verifying interactions, capturing arguments, or deciding between mocks, fakes, and real objects.
+intents: [test]
+stacks: [flutter]
+source: https://github.com/evanca/flutter-ai-rules
+license: MIT
+---
+
+# Mockito Skill
+
+This skill defines how to correctly use the `mockito` package for mocking in Dart and Flutter tests.
+
+---
+
+## 1. Mock vs. Fake vs. Real Object
+
+| Use | When |
+|---|---|
+| **Real object** | Prefer over mocks when practical. |
+| **Fake** (`extends Fake`) | Lightweight custom implementation; override only the methods you need. Prefer over mocks when you don't need interaction verification. |
+| **Mock** (`extends Mock`) | Only when you need to **verify interactions** (call counts, arguments) or stub dynamic responses. |
+
+- **Data models** should not be mocked if they can be constructed with stubbed data.
+- Only use mocks if your test has `verify` assertions; otherwise prefer real or fake objects.
+
+---
+
+## 2. Generating Mocks
+
+```dart
+@GenerateMocks([MyClass])
+// or for nice mocks (return simple legal values for missing stubs):
+@GenerateNiceMocks([MockSpec<MyClass>()])
+void main() { ... }
+```
+
+```bash
+dart run build_runner build
+```
+
+- Only annotate files under `test/` for mock generation by default.
+- Use a `build.yaml` if you need to generate mocks outside of `test/`.
+- Never add `@override` methods or implementations to a class extending `Mock`.
+- Never stub responses in a mock's constructor or inside the mock class — always stub in your tests.
+
+---
+
+## 3. Stubbing
+
+```dart
+final mock = MockCat();
+
+// Return a value
+when(mock.sound()).thenReturn('Meow');
+
+// Throw an error
+when(mock.sound()).thenThrow(Exception('No sound'));
+
+// Calculate response at call time
+when(mock.sound()).thenAnswer((_) => computedValue);
+
+// Return values in sequence
+when(mock.sound()).thenReturnInOrder(['Meow', 'Purr']);
+```
+
+- Always stub methods/getters **before** using them if you need specific return values.
+- Missing stub behavior: `@GenerateMocks` → throws; `@GenerateNiceMocks` → returns a simple legal value.
+- Use `throwOnMissingStub(mock)` to throw on any unstubbed call.
+
+---
+
+## 4. Verification
+
+```dart
+verify(mock.sound());                  // called at least once
+verifyNever(mock.eat(any));            // never called
+verify(mock.sound()).called(2);        // called exactly twice
+```
+
+**Async:**
+
+```dart
+await untilCalled(mock.sound());       // wait for the interaction
+```
+
+---
+
+## 5. Argument Matchers
+
+```dart
+// Flexible stubbing
+when(mock.eat(any)).thenReturn(true);
+when(mock.eat(argThat(isNotNull))).thenReturn(true);
+
+// Named arguments
+when(mock.fetch(any, headers: any)).thenReturn(response);
+```
+
+- Do **not** use `null` as an argument adjacent to an argument matcher.
+- For named arguments, use `any` or `argThat` as values, not as argument names.
+
+---
+
+## 6. Capturing Arguments
+
+```dart
+final captured = verify(mock.eat(captureAny)).captured;
+print(captured.last); // last captured argument
+```
+
+Use `captureThat` for conditional capturing.
+
+---
+
+## 7. Resetting Mocks
+
+```dart
+reset(mock);                  // clear all stubs AND interactions
+clearInteractions(mock);      // clear only recorded interactions
+```
+
+---
+
+## 8. Mocking Function Types
+
+To mock a function type (e.g., a callback), define an abstract class with the required signature and generate mocks for it:
+
+```dart
+abstract class Callback {
+  void call(String value);
+}
+
+@GenerateMocks([Callback])
+```
+
+---
+
+## 9. Debugging
+
+```dart
+logInvocations([mock1, mock2]); // print all collected invocations
+```
+
+---
+
+## References
+
+- [Mockito GitHub Repository](https://github.com/dart-lang/mockito)

package/skills/mocktail/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: mocktail
+description: Uses the Mocktail package for mocking in Flutter/Dart tests. Use when creating mocks, stubbing methods, verifying interactions, registering fallback values, or deciding between mocks, fakes, and real objects.
+intents: [test]
+stacks: [flutter]
+source: https://github.com/evanca/flutter-ai-rules
+license: MIT
+---
+
+# Mocktail Skill
+
+This skill defines how to correctly use the `mocktail` package for mocking in Dart and Flutter tests.
+
+---
+
+## 1. Mock vs. Fake vs. Real Object
+
+| Use | When |
+|---|---|
+| **Real object** | Prefer over mocks when practical. |
+| **Fake** (`extends Fake`) | Lightweight custom implementation; override only the methods you need. Prefer over mocks when you don't need interaction verification. |
+| **Mock** (`extends Mock`) | Only when you need to **verify interactions** (call counts, arguments) or stub dynamic responses. |
+
+- Never add `@override` methods or implementations to a class extending `Mock`.
+- Only use mocks if your test has `verify` assertions; otherwise prefer real or fake objects.
+
+---
+
+## 2. Creating Mocks
+
+```dart
+class MockMyService extends Mock implements MyService {}
+class FakeMyEvent extends Fake implements MyEvent {}
+```
+
+No code generation required — unlike Mockito, Mocktail uses `noSuchMethod` at runtime.
+
+---
+
+## 3. Registering Fallback Values
+
+Register fallback values **before** using custom types with argument matchers. Do this in `setUpAll` or at the top of your test:
+
+```dart
+setUpAll(() {
+  registerFallbackValue(FakeMyEvent());
+});
+```
+
+- Required for non-nullable custom types used with `any()`, `captureAny()`, or `captureThat()`.
+- Register fallback values for **any** custom type used with argument matchers.
+
+---
+
+## 4. Stubbing
+
+```dart
+final mock = MockMyService();
+
+// Return a value
+when(() => mock.fetchData()).thenReturn('result');
+
+// Throw an error
+when(() => mock.fetchData()).thenThrow(Exception('error'));
+
+// Dynamic/async response
+when(() => mock.fetchData()).thenAnswer((_) async => 'result');
+
+// Future<void>
+when(() => mock.doWork()).thenAnswer((_) async {});
+```
+
+- Always stub async methods (returning `Future` or `Future<void>`) with `thenAnswer`.
+- Stub every method you expect to be called, even if it's not the focus of your test.
+
+---
+
+## 5. Named Parameters
+
+Always include **all named parameters** in both `when` and `verify` calls. Use `any(named: 'paramName')` for those you don't care about:
+
+```dart
+when(() => mock.fetch(
+  id: any(named: 'id'),
+  headers: any(named: 'headers'),
+)).thenReturn(response);
+```
+
+- If a method has default values for named parameters, Mocktail still expects them all to be matched.
+
+---
+
+## 6. Verification
+
+```dart
+verify(() => mock.fetchData());             // called at least once
+verifyNever(() => mock.fetchData());        // never called
+verify(() => mock.fetchData()).called(2);   // called exactly twice
+```
+
+---
+
+## 7. Argument Matchers
+
+```dart
+// Any positional argument
+when(() => mock.process(any())).thenReturn(true);
+
+// Capture arguments for later assertions
+final captured = verify(() => mock.process(captureAny())).captured;
+print(captured.last);
+```
+
+- Use `any()` for positional parameters when you don't care about the exact value.
+- Use `captureThat()` for conditional capturing.
+- When matching string output, be aware of what `.toString()` returns for the type.
+
+---
+
+## References
+
+- [Mocktail GitHub Repository](https://github.com/felangel/mocktail)

package/skills/patrol-e2e-testing/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: patrol-e2e-testing
+description: Generates and maintains end-to-end tests for Flutter apps using Patrol. Use when adding E2E coverage for new features, regression tests for UI bugs, or testing native interactions (permissions, system dialogs, deep links)
+intents: [test]
+stacks: [flutter]
+source: https://github.com/evanca/flutter-ai-rules
+license: MIT
+---
+
+# Patrol E2E Testing Skill
+
+This skill defines how to design, implement, and run end-to-end (E2E) tests using Patrol 4.x in Flutter projects.
+
+It focuses on:
+
+* Covering new feature flows with deterministic UI tests
+* Converting reproducible UI bugs into regression tests
+* Handling native OS interactions
+* Running tests locally and in CI using correct Patrol CLI commands
+
+## When to Use
+
+Use this skill when:
+
+* A new screen or user flow must be covered with E2E tests.
+* A feature interacts with native components (permissions, notifications, system dialogs).
+* A UI bug should be captured as a regression test.
+* Cross-platform behavior (Android / iOS / Web) must be validated.
+
+## Setup
+
+For installation and project initialization, follow the official documentation:
+
+[https://patrol.leancode.co/documentation#setup](https://patrol.leancode.co/documentation#setup)
+
+Key Patrol conventions:
+
+* `patrol` is added as a dev dependency.
+* Tests live in `patrol_test/`.
+* Test files must end with `_test.dart`.
+* Tests are executed with `patrol test`.
+
+## How to use this skill
+
+Follow the steps below when implementing or updating Patrol tests.
+
+### 1. Identify the user journey
+
+Break the feature into:
+
+* **Actions**: taps, scrolls, input, navigation, deep links.
+* **Observable outcomes**: visible text, screen changes, enabled buttons, dialogs.
+
+Rules:
+
+* One test per primary (happy-path) journey.
+* Separate tests for critical edge cases.
+* Avoid combining unrelated flows in a single test.
+
+### 2. Structure the Patrol test
+
+Basic Patrol structure:
+
+```dart
+import 'package:flutter_test/flutter_test.dart';
+import 'package:patrol/patrol.dart';
+
+void main() {
+  patrolTest(
+    'user can log in successfully',
+    ($) async {
+      await $.pumpWidgetAndSettle(const MyApp());
+
+      const email = String.fromEnvironment('E2E_EMAIL');
+      const password = String.fromEnvironment('E2E_PASSWORD');
+
+      await $(#emailField).enterText(email);
+      await $(#passwordField).enterText(password);
+      await $(#loginButton).tap();
+
+      await $.waitUntilVisible($(#homeScreenTitle));
+
+      expect($(#homeScreenTitle).text, equals('Welcome'));
+    },
+  );
+}
+```
+
+Key concepts:
+
+* Use `patrolTest()` instead of `testWidgets()`.
+* `$` is the Patrol tester.
+* Use `$(#keyName)` to find widgets by `Key`.
+* Use explicit wait conditions (e.g., `waitUntilVisible`).
+
+### 3. Handle native dialogs
+
+For OS-level permission dialogs:
+
+```dart
+patrolTest('grants camera permission', ($) async {
+  await $.pumpWidgetAndSettle(const MyApp());
+
+  await $(#openCameraButton).tap();
+
+  if (await $.native.isPermissionDialogVisible()) {
+    await $.native.grantPermission();
+  }
+
+  await $.waitUntilVisible($(#cameraPreview));
+});
+```
+
+Use native automation only when required by the feature.
+
+### 4. Selector & interaction quick reference
+
+**Finding widgets:**
+
+```dart
+$('some text')        // by text
+$(TextField)          // by type
+$(Icons.arrow_back)   // by icon
+```
+
+**Tapping:**
+
+```dart
+// Tap a widget containing a specific text label
+await $(Container).$('click').tap();
+
+// Tap a container that contains an ElevatedButton
+await $(Container).containing(ElevatedButton).tap();
+
+// Tap only the enabled ElevatedButton
+await $(ElevatedButton)
+    .which<ElevatedButton>(
+      (b) => b.enabled,
+    )
+    .tap();
+```
+
+**Entering text:**
+
+```dart
+// Enter text into the second TextField on screen
+await $(TextField).at(1).enterText('your input');
+```
+
+**Scrolling:**
+
+```dart
+await $(widget_you_want_to_scroll_to).scrollTo();
+```
+
+**Native interactions:**
+
+```dart
+// Grant permission while app is in use
+await $.native.grantPermissionWhenInUse();
+
+// Open notification shade and tap a notification by text
+await $.native.openNotifications();
+await $.native.tapOnNotificationBySelector(
+  Selector(textContains: 'text'),
+);
+```
+
+### 5. Running Patrol tests
+
+Run all tests:
+
+```bash
+patrol test
+```
+
+Run a specific file with live reload (development mode):
+
+```bash
+patrol develop -t integration_test/my_test.dart
+```
+
+Run a specific file:
+
+```bash
+patrol test --target patrol_test/login_test.dart
+```
+
+Run on web:
+
+```bash
+patrol test --device chrome
+```
+
+Headless web (CI):
+
+```bash
+patrol test --device chrome --web-headless true
+```
+
+Filter by tags:
+
+```bash
+patrol test --tags android
+```
+
+### Output requirements when this skill is used
+
+When applied, this skill must produce:
+
+1. Patrol test(s) covering the specified feature.
+2. Any required widget key additions.
+3. Exact `patrol test` command(s) to execute locally.
+4. Notes explaining stabilization decisions.
+
+### Quality bar
+
+A valid Patrol test must be:
+
+* Deterministic (no arbitrary delays)
+* Readable
+* Minimal but complete
+* Secret-safe (no hardcoded credentials)
+* CI-ready

package/skills/provider/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: provider
+description: Uses the Provider package for dependency injection and state management in Flutter. Use when setting up providers, consuming state, optimizing rebuilds, using ProxyProvider, or migrating from deprecated providers.
+routing: manual
+stacks: [flutter]
+source: https://github.com/evanca/flutter-ai-rules
+license: MIT
+---
+
+# Provider Skill
+
+This skill defines how to correctly use the `provider` package in Flutter applications.
+
+---
+
+## 1. Provider Types
+
+| Provider | Use for |
+|---|---|
+| `Provider` | Exposing any immutable value |
+| `ChangeNotifierProvider` | Mutable state with `ChangeNotifier` |
+| `FutureProvider` | Exposing a `Future` result |
+| `StreamProvider` | Exposing a `Stream` |
+| `ProxyProvider` / `ChangeNotifierProxyProvider` | Objects that depend on other providers |
+
+---
+
+## 2. Setup
+
+```dart
+MultiProvider(
+  providers: [
+    Provider<Something>(create: (_) => Something()),
+    ChangeNotifierProvider(create: (_) => MyNotifier()),
+    FutureProvider<String>(create: (_) => fetchData(), initialData: ''),
+  ],
+  child: MyApp(),
+)
+```
+
+- Use `MultiProvider` to group multiple providers and avoid deeply nested trees.
+- `ChangeNotifierProvider` **automatically disposes** the model when it is no longer needed.
+- **Never** create a provider's object from variables that can change over time — the object won't update when the variable changes. Use `ProxyProvider` instead.
+- If you have 150+ providers, consider mounting them over time (e.g., during a splash screen) rather than all at once to avoid `StackOverflowError`.
+
+---
+
+## 3. Consuming State
+
+Always specify the **generic type** for type safety:
+
+```dart
+// Listen and rebuild on change
+final count = context.watch<MyModel>().count;
+
+// Access without listening (use in callbacks)
+context.read<MyModel>().increment();
+
+// Listen to only part of the state
+final count = context.select<MyModel, int>((m) => m.count);
+```
+
+Use `Consumer<T>` or `Selector<T, R>` widgets when you need fine-grained rebuilds and cannot access a descendant `BuildContext`:
+
+```dart
+Consumer<MyModel>(
+  builder: (context, model, child) => Text('${model.count}'),
+  child: const ExpensiveWidget(), // rebuilt only once
+)
+
+Selector<MyModel, int>(
+  selector: (_, model) => model.count,
+  builder: (_, count, __) => Text('$count'),
+)
+```
+
+---
+
+## 4. ProxyProvider
+
+Use `ProxyProvider` or `ChangeNotifierProxyProvider` for objects that depend on other providers or values that can change:
+
+```dart
+MultiProvider(
+  providers: [
+    Provider<Auth>(create: (_) => Auth()),
+    ProxyProvider<Auth, Api>(
+      update: (_, auth, __) => Api(auth.token),
+    ),
+  ],
+)
+```
+
+---
+
+## 5. Rules
+
+- Do **not** access providers inside `initState` or constructors — use them in `build`, callbacks, or lifecycle methods where the widget is fully mounted.
+- You can use **any object** as state, not just `ChangeNotifier`; use `Provider.value()` with a `StatefulWidget` if needed.
+
+---
+
+## 6. Debugging
+
+Implement `toString` or `DiagnosticableTreeMixin` to improve how your objects appear in Flutter DevTools:
+
+```dart
+class MyModel with DiagnosticableTreeMixin {
+  final int count;
+  MyModel(this.count);
+
+  @override
+  String toString() => 'MyModel(count: $count)';
+}
+```
+
+---
+
+## 7. Migration: ValueListenableProvider
+
+`ValueListenableProvider` is deprecated. Use `Provider` with `ValueListenableBuilder` instead:
+
+```dart
+ValueListenableBuilder<int>(
+  valueListenable: myValueListenable,
+  builder: (context, value, _) {
+    return Provider<int>.value(
+      value: value,
+      child: MyApp(),
+    );
+  },
+)
+```
+
+---
+
+## References
+
+- [Provider GitHub Repository](https://github.com/rrousselGit/provider)