@bdayadev/flutter-ultra-mcp 1.11.7 → 1.13.0

package/skills/add-widget-test/SKILL.md

@@ -0,0 +1,171 @@
+---
+name: add-widget-test
+description: Implement a component-level test using `WidgetTester` to verify UI rendering and user interactions (tapping, scrolling, entering text). Use when validating that a specific widget displays correct data and responds to events as expected.
+  last_modified: Tue, 21 Apr 2026 21:15:41 GMT
+---
+
+# Writing Flutter Widget Tests
+
+## Contents
+
+- [Setup & Configuration](#setup--configuration)
+- [Core Components](#core-components)
+- [Workflow: Implementing a Widget Test](#workflow-implementing-a-widget-test)
+- [Interaction & State Management](#interaction--state-management)
+- [Examples](#examples)
+
+## Setup & Configuration
+
+Ensure the testing environment is properly configured before authoring widget tests.
+
+1. Add the `flutter_test` dependency to the `dev_dependencies` section of `pubspec.yaml`.
+2. Place all test files in the `test/` directory at the root of the project.
+3. Suffix all test file names with `_test.dart` (e.g., `widget_test.dart`).
+
+## Core Components
+
+Utilize the following `flutter_test` components to interact with and validate the widget tree:
+
+- **`WidgetTester`**: The primary interface for building and interacting with widgets in the test environment. Provided automatically by the `testWidgets()` function.
+- **`Finder`**: Locates widgets in the test environment (e.g., `find.text('Submit')`, `find.byType(TextField)`, `find.byKey(Key('submit_btn'))`).
+- **`Matcher`**: Verifies the presence or state of widgets located by a `Finder` (e.g., `findsOneWidget`, `findsNothing`, `findsNWidgets(2)`, `matchesGoldenFile`).
+
+## Workflow: Implementing a Widget Test
+
+Copy the following checklist to track progress when implementing a new widget test.
+
+### Task Progress
+
+- [ ] **Step 1: Define the test.** Use `testWidgets('description', (WidgetTester tester) async { ... })`.
+- [ ] **Step 2: Build the widget.** Call `await tester.pumpWidget(MyWidget())` to render the UI. Wrap the widget in a `MaterialApp` or `Directionality` widget if it requires inherited directional or theme data.
+- [ ] **Step 3: Locate elements.** Instantiate `Finder` objects for the target widgets.
+- [ ] **Step 4: Verify initial state.** Use `expect(finder, matcher)` to validate the initial render.
+- [ ] **Step 5: Simulate interactions.** Execute gestures or inputs (e.g., `await tester.tap(buttonFinder)`).
+- [ ] **Step 6: Rebuild the tree.** Call `await tester.pump()` or `await tester.pumpAndSettle()` to process state changes.
+- [ ] **Step 7: Verify updated state.** Use `expect()` to validate the UI after the interaction.
+- [ ] **Step 8: Run and validate.** Execute `flutter test test/your_test_file_test.dart`.
+- [ ] **Step 9: Feedback Loop.** Review test output -> identify failing matchers -> adjust widget logic or test assertions -> re-run until passing.
+
+## Interaction & State Management
+
+Apply the following conditional logic based on the type of interaction or state change being tested:
+
+- **If testing static rendering:** Call `await tester.pumpWidget()` once, then immediately run `expect()` assertions.
+- **If testing standard state changes (e.g., button taps):**
+  1. Call `await tester.tap(finder)`.
+  2. Call `await tester.pump()` to trigger a single frame rebuild.
+- **If testing animations, transitions, or asynchronous UI updates:**
+  1. Trigger the action (e.g., `await tester.drag(finder, Offset(500, 0))`).
+  2. Call `await tester.pumpAndSettle()` to repeatedly pump frames until no more frames are scheduled (animation completes).
+- **If testing text input:** Call `await tester.enterText(textFieldFinder, 'Input string')`.
+- **If testing items in a dynamic or long list:** Call `await tester.scrollUntilVisible(itemFinder, 500.0, scrollable: listFinder)` to ensure the target widget is rendered before interacting with it.
+
+## Examples
+
+### High-Fidelity Widget Test Implementation
+
+**Target Widget (`lib/todo_list.dart`):**
+
+```dart
+import 'package:flutter/material.dart';
+
+class TodoList extends StatefulWidget {
+  const TodoList({super.key});
+
+  @override
+  State<TodoList> createState() => _TodoListState();
+}
+
+class _TodoListState extends State<TodoList> {
+  final todos = <String>[];
+  final controller = TextEditingController();
+
+  @override
+  Widget build(BuildContext context) {
+    return MaterialApp(
+      home: Scaffold(
+        body: Column(
+          children: [
+            TextField(controller: controller),
+            Expanded(
+              child: ListView.builder(
+                itemCount: todos.length,
+                itemBuilder: (context, index) {
+                  final todo = todos[index];
+                  return Dismissible(
+                    key: Key('$todo$index'),
+                    onDismissed: (_) => setState(() => todos.removeAt(index)),
+                    child: ListTile(title: Text(todo)),
+                  );
+                },
+              ),
+            ),
+          ],
+        ),
+        floatingActionButton: FloatingActionButton(
+          onPressed: () {
+            setState(() {
+              todos.add(controller.text);
+              controller.clear();
+            });
+          },
+          child: const Icon(Icons.add),
+        ),
+      ),
+    );
+  }
+}
+```
+
+**Test Implementation (`test/todo_list_test.dart`):**
+
+```dart
+import 'package:flutter/material.dart';
+import 'package:flutter_test/flutter_test.dart';
+import 'package:my_app/todo_list.dart';
+
+void main() {
+  testWidgets('Add and remove a todo item', (WidgetTester tester) async {
+    // 1. Build the widget
+    await tester.pumpWidget(const TodoList());
+
+    // 2. Verify initial state
+    expect(find.byType(ListTile), findsNothing);
+
+    // 3. Enter text into the TextField
+    await tester.enterText(find.byType(TextField), 'Buy groceries');
+
+    // 4. Tap the add button
+    await tester.tap(find.byType(FloatingActionButton));
+
+    // 5. Rebuild the widget to reflect the new state
+    await tester.pump();
+
+    // 6. Verify the item was added
+    expect(find.text('Buy groceries'), findsOneWidget);
+
+    // 7. Swipe the item to dismiss it
+    await tester.drag(find.byType(Dismissible), const Offset(500, 0));
+
+    // 8. Build the widget until the dismiss animation ends
+    await tester.pumpAndSettle();
+
+    // 9. Verify the item was removed
+    expect(find.text('Buy groceries'), findsNothing);
+  });
+}
+```
+
+## Flutter Ultra Integration
+
+After writing the widget test, run and validate it with these tools:
+
+- `mcp__plugin_flutter_flutter-ultra-build__start_run_widget_tests` — Execute widget tests (supports `testNamePattern` to scope)
+- `mcp__plugin_flutter_flutter-ultra-build__poll_run_widget_tests` — Monitor test progress until completion
+- `mcp__plugin_flutter_flutter-ultra-build__get_run_widget_tests_result` — Get detailed results: passed, failed, skipped, per-failure info
+- `mcp__plugin_flutter_flutter-ultra-build__analyze` — Static analysis before running tests
+
+---
+
+> **Attribution:** This skill is vendored from [flutter/skills](https://github.com/flutter/skills) (BSD-3-Clause).
+> Synced by `scripts/sync-upstream-skills.mjs`. Do not edit manually — changes will be overwritten on next sync.

package/skills/apply-architecture-best-practices/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: apply-architecture-best-practices
+description: Architects a Flutter application using the recommended layered approach (UI, Logic, Data). Use when structuring a new project or refactoring for scalability.
+  last_modified: Tue, 21 Apr 2026 20:11:20 GMT
+---
+
+# Architecting Flutter Applications
+
+## Contents
+
+- [Architectural Layers](#architectural-layers)
+- [Project Structure](#project-structure)
+- [Workflow: Implementing a New Feature](#workflow-implementing-a-new-feature)
+- [Examples](#examples)
+
+## Architectural Layers
+
+Enforce strict Separation of Concerns by dividing the application into distinct layers. Never mix UI rendering with business logic or data fetching.
+
+### UI Layer (Presentation)
+
+Implement the MVVM (Model-View-ViewModel) pattern to manage UI state and logic.
+
+- **Views:** Write reusable, lean widgets. Restrict logic in Views to UI-specific operations (e.g., animations, layout constraints, simple routing). Pass all required data from the ViewModel.
+- **ViewModels:** Manage UI state and handle user interactions. Extend `ChangeNotifier` (or use `Listenable`) to expose state. Expose immutable state snapshots to the View. Inject Repositories into ViewModels via the constructor.
+
+### Data Layer
+
+Implement the Repository pattern to isolate data access logic and create a single source of truth.
+
+- **Services:** Create stateless classes to wrap external APIs (HTTP clients, local databases, platform plugins). Return raw API models or `Result` wrappers.
+- **Repositories:** Consume one or more Services. Transform raw API models into clean Domain Models. Handle caching, offline synchronization, and retry logic. Expose Domain Models to ViewModels.
+
+### Logic Layer (Domain - Optional)
+
+- **Use Cases:** Implement this layer only if the application contains complex business logic that clutters the ViewModel, or if logic must be reused across multiple ViewModels. Extract this logic into dedicated Use Case (interactor) classes that sit between ViewModels and Repositories.
+
+## Project Structure
+
+Organize the codebase using a hybrid approach: group UI components by feature, and group Data/Domain components by type.
+
+```text
+lib/
+├── data/
+│   ├── models/         # API models
+│   ├── repositories/   # Repository implementations
+│   └── services/       # API clients, local storage wrappers
+├── domain/
+│   ├── models/         # Clean domain models
+│   └── use_cases/      # Optional business logic classes
+└── ui/
+    ├── core/           # Shared widgets, themes, typography
+    └── features/
+        └── [feature_name]/
+            ├── view_models/
+            └── views/
+```
+
+## Workflow: Implementing a New Feature
+
+Follow this sequential workflow when adding a new feature to the application. Copy the checklist to track progress.
+
+### Task Progress
+
+- [ ] **Step 1: Define Domain Models.** Create immutable data classes for the feature using `freezed` or `built_value`.
+- [ ] **Step 2: Implement Services.** Create or update Service classes to handle external API communication.
+- [ ] **Step 3: Implement Repositories.** Create the Repository to consume Services and return Domain Models.
+- [ ] **Step 4: Apply Conditional Logic (Domain Layer).**
+  - _If the feature requires complex data transformation or cross-repository logic:_ Create a Use Case class.
+  - _If the feature is a simple CRUD operation:_ Skip to Step 5.
+- [ ] **Step 5: Implement the ViewModel.** Create the ViewModel extending `ChangeNotifier`. Inject required Repositories/Use Cases. Expose immutable state and command methods.
+- [ ] **Step 6: Implement the View.** Create the UI widget. Use `ListenableBuilder` or `AnimatedBuilder` to listen to ViewModel changes.
+- [ ] **Step 7: Inject Dependencies.** Register the new Service, Repository, and ViewModel in the dependency injection container (e.g., `provider` or `get_it`).
+- [ ] **Step 8: Run Validator.** Execute unit tests for the ViewModel and Repository.
+  - _Feedback Loop:_ Run tests -> Review failures -> Fix logic -> Re-run until passing.
+
+## Examples
+
+### Data Layer: Service and Repository
+
+```dart
+// 1. Service (Raw API interaction)
+class ApiClient {
+  Future<UserApiModel> fetchUser(String id) async {
+    // HTTP GET implementation...
+  }
+}
+
+// 2. Repository (Single source of truth, returns Domain Model)
+class UserRepository {
+  UserRepository({required ApiClient apiClient}) : _apiClient = apiClient;
+
+  final ApiClient _apiClient;
+  User? _cachedUser;
+
+  Future<User> getUser(String id) async {
+    if (_cachedUser != null) return _cachedUser!;
+
+    final apiModel = await _apiClient.fetchUser(id);
+    _cachedUser = User(id: apiModel.id, name: apiModel.fullName); // Transform to Domain Model
+    return _cachedUser!;
+  }
+}
+```
+
+### UI Layer: ViewModel and View
+
+```dart
+// 3. ViewModel (State management and presentation logic)
+class ProfileViewModel extends ChangeNotifier {
+  ProfileViewModel({required UserRepository userRepository})
+      : _userRepository = userRepository;
+
+  final UserRepository _userRepository;
+
+  User? _user;
+  User? get user => _user;
+
+  bool _isLoading = false;
+  bool get isLoading => _isLoading;
+
+  Future<void> loadProfile(String id) async {
+    _isLoading = true;
+    notifyListeners();
+
+    try {
+      _user = await _userRepository.getUser(id);
+    } finally {
+      _isLoading = false;
+      notifyListeners();
+    }
+  }
+}
+
+// 4. View (Dumb UI component)
+class ProfileView extends StatelessWidget {
+  const ProfileView({super.key, required this.viewModel});
+
+  final ProfileViewModel viewModel;
+
+  @override
+  Widget build(BuildContext context) {
+    return ListenableBuilder(
+      listenable: viewModel,
+      builder: (context, _) {
+        if (viewModel.isLoading) {
+          return const Center(child: CircularProgressIndicator());
+        }
+
+        final user = viewModel.user;
+        if (user == null) {
+          return const Center(child: Text('User not found'));
+        }
+
+        return Column(
+          children: [
+            Text(user.name),
+            ElevatedButton(
+              onPressed: () => viewModel.loadProfile(user.id),
+              child: const Text('Refresh'),
+            ),
+          ],
+        );
+      },
+    );
+  }
+}
+```
+
+## Flutter Ultra Integration
+
+Use these tools to audit and validate architectural decisions:
+
+- `mcp__plugin_flutter_flutter-ultra-build__list_projects` — Discover all projects in the workspace
+- `mcp__plugin_flutter_flutter-ultra-build__project_info` — Get project structure, dependencies, and entry points
+- `mcp__plugin_flutter_flutter-ultra-build__analyze` — Run static analysis to catch architectural violations
+- `mcp__plugin_flutter_flutter-ultra-build__pub_deps` — Review dependency graph for layering issues
+
+---
+
+> **Attribution:** This skill is vendored from [flutter/skills](https://github.com/flutter/skills) (BSD-3-Clause).
+> Synced by `scripts/sync-upstream-skills.mjs`. Do not edit manually — changes will be overwritten on next sync.

package/skills/build-cli-app/SKILL.md

@@ -0,0 +1,200 @@
+---
+name: build-cli-app
+description: Entrypoint structure, exit codes, cross-platform scripts. Use when building command line utilities, scripts, or applications.
+  last_modified: Fri, 04 May 2026 17:41:00 GMT
+---
+
+# Building Dart CLI Applications
+
+## Contents
+
+- [Project Setup & Architecture](#project-setup--architecture)
+- [Argument Parsing & Command Routing](#argument-parsing--command-routing)
+- [Execution & Error Handling](#execution--error-handling)
+- [Testing CLI Applications](#testing-cli-applications)
+- [Compilation & Distribution](#compilation--distribution)
+- [Workflows](#workflows)
+- [Examples](#examples)
+
+## Project Setup & Architecture
+
+Initialize new CLI projects using the official Dart template to ensure standard directory structures.
+
+- Run `dart create -t cli <project_name>` to scaffold a console application with basic argument parsing.
+- Place executable entry points (files containing `main()`) exclusively in the `bin/` directory.
+- Place internal implementation logic in `lib/src/` and expose public APIs via `lib/<project_name>.dart`.
+- Enforce formatting in CI environments by running `dart format . --set-exit-if-changed`. This returns exit code 1 if formatting violations exist.
+
+## Argument Parsing & Command Routing
+
+Import the `args` package to manage command-line arguments, flags, and subcommands.
+
+- If building a simple script: Use `ArgParser` directly to define flags (`addFlag`) and options (`addOption`).
+- If building a complex, multi-command CLI (like `git`): Implement `CommandRunner` and extend `Command` for each subcommand.
+- Define global arguments on the `CommandRunner.argParser` and command-specific arguments on the individual `Command.argParser`.
+- Catch `UsageException` to gracefully handle invalid arguments and display the automatically generated help text.
+- **Validate Help Text Accuracy**: Ensure the help text provides all necessary information to run the tool. If the help text references a compiled executable name, and the user needs to add it to their PATH to run it that way, provide clear instructions on how to do so in the help text or description.
+
+## Execution & Error Handling
+
+Leverage the `io` and `stack_trace` packages to build robust, production-ready CLI tools.
+
+- Use the `io` package's `ExitCode` enum to return standard POSIX exit codes (e.g., `ExitCode.success.code`, `ExitCode.usage.code`).
+- Use `sharedStdIn` from the `io` package if multiple asynchronous listeners need sequential access to standard input.
+- Wrap the application execution in `Chain.capture()` from the `stack_trace` package to track asynchronous stack chains.
+- Format output stack traces using `Trace.terse` or `Chain.terse` to strip noisy core library frames and present readable errors to the user.
+- **Do not swallow exceptions** in lower-level logic or storage classes unless recovery is possible. Let them bubble up or rethrow them so higher-level commands know operations failed.
+- **Fail fast and with non-zero exit codes**: Ensure operation failures result in descriptive error messages to `stderr` and appropriate non-zero exit codes (e.g., using `exit(1)` or triggering a 64 exit code after a caught `UsageException`).
+
+## Testing CLI Applications
+
+> [!IMPORTANT]
+> **All new commands and significant features must be covered by automated tests.** Manual verification is not sufficient for testing logic. However, manual verification of help text and user experience (UX) is still required to ensure the interface is intuitive and correct.
+
+Use `test_process` and `test_descriptor` to write high-fidelity integration tests for your CLI.
+
+- Define expected filesystem states using `test_descriptor` (`d.dir`, `d.file`).
+- Create the mock filesystem before execution using `await d.Descriptor.create()`.
+- Spawn the CLI process using `TestProcess.start('dart', ['run', 'bin/cli.dart', ...args])`.
+- Validate standard output and error streams using `StreamQueue` matchers (e.g., `emitsThrough`, `emits`).
+- Assert the final exit code using `await process.shouldExit(0)`.
+- Validate resulting filesystem mutations using `await d.Descriptor.validate()`.
+
+## Compilation & Distribution
+
+Select the appropriate compilation target based on your distribution requirements.
+
+- **If testing locally during development:** Use `dart run bin/cli.dart`. This uses the JIT compiler for rapid iteration.
+- **If bundling code assets and dynamic libraries:** Use `dart build cli`. This runs build hooks and outputs to `build/cli/_/bundle/`.
+- **If distributing a standalone native executable:** Use `dart compile exe bin/cli.dart -o <output_path>`. This bundles the Dart runtime and machine code into a single file.
+- **If distributing multiple apps with strict disk space limits:** Use `dart compile aot-snapshot bin/cli.dart`. Run the resulting `.aot` file using `dartaotruntime`.
+
+<details>
+<summary>Cross-Compilation Targets (Linux Only)</summary>
+
+Dart supports cross-compiling to Linux from macOS, Windows, or Linux hosts.
+Use the `--target-os` and `--target-arch` flags with `dart compile exe` or `dart compile aot-snapshot`.
+
+- `--target-os=linux` (Only Linux is currently supported as a cross-compilation target)
+- `--target-arch=arm64` (64-bit ARM)
+- `--target-arch=x64` (x86-64)
+- `--target-arch=arm` (32-bit ARM)
+- `--target-arch=riscv64` (64-bit RISC-V)
+
+Example: `dart compile exe --target-os=linux --target-arch=arm64 bin/cli.dart`
+
+</details>
+
+## Workflows
+
+### Task Progress: Implement a New CLI Command
+
+- [ ] Create a new class extending `Command` in `lib/src/commands/`.
+- [ ] Define the `name` and `description` properties.
+- [ ] Register command-specific flags in the constructor using `argParser.addFlag()` or `argParser.addOption()`.
+- [ ] Implement the `run()` method with the core logic.
+- [ ] Register the new command in the `CommandRunner` instance in `bin/cli.dart` using `addCommand()`.
+- [ ] Create tests for the new command in the `test/` directory using `test_process` or standard tests.
+- [ ] Run validator -> Execute `dart run bin/cli.dart help <command_name>` to verify help text generation.
+- [ ] Verify final UX: Compile the application using `dart compile exe` and run the resulting executable to verify the target user experience (e.g., `./bin/cli <command>`).
+
+### Task Progress: Compile and Release Native Executable
+
+- [ ] Run validator -> Execute `dart format . --set-exit-if-changed` to ensure code formatting.
+- [ ] Run validator -> Execute `dart analyze` to ensure no static analysis errors.
+- [ ] Run validator -> Execute `dart test` to pass all integration tests.
+- [ ] Compile for host OS: `dart compile exe bin/cli.dart -o build/cli-host`
+- [ ] Compile for Linux (if host is macOS/Windows): `dart compile exe --target-os=linux --target-arch=x64 bin/cli.dart -o build/cli-linux-x64`
+
+## Examples
+
+### Example: CommandRunner Implementation
+
+```dart
+import 'dart:io';
+import 'package:args/command_runner.dart';
+import 'package:stack_trace/stack_trace.dart';
+
+class CommitCommand extends Command {
+  @override
+  final String name = 'commit';
+  @override
+  final String description = 'Record changes to the repository.';
+
+  CommitCommand() {
+    argParser.addFlag('all', abbr: 'a', help: 'Commit all changed files.');
+  }
+
+  @override
+  Future<void> run() async {
+    final commitAll = argResults?['all'] as bool? ?? false;
+    print('Committing... (All: $commitAll)');
+  }
+}
+
+void main(List<String> args) {
+  Chain.capture(() async {
+    final runner = CommandRunner('dgit', 'Distributed version control.')
+      ..addCommand(CommitCommand());
+
+    await runner.run(args);
+  }, onError: (error, chain) {
+    if (error is UsageException) {
+      stderr.writeln(error.message);
+      stderr.writeln(error.usage);
+      exit(64); // ExitCode.usage.code
+    } else {
+      stderr.writeln('Fatal error: $error');
+      stderr.writeln(chain.terse);
+      exit(1);
+    }
+  });
+}
+```
+
+### Example: Integration Testing with Subprocesses
+
+```dart
+import 'package:test/test.dart';
+import 'package:test_process/test_process.dart';
+import 'package:test_descriptor/test_descriptor.dart' as d;
+
+void main() {
+  test('CLI formats output correctly and modifies filesystem', () async {
+    // 1. Setup mock filesystem
+    await d.dir('project', [
+      d.file('config.json', '{"key": "value"}')
+    ]).create();
+
+    // 2. Spawn the CLI process
+    final process = await TestProcess.start(
+      'dart',
+      ['run', 'bin/cli.dart', 'process', '--path', '${d.sandbox}/project']
+    );
+
+    // 3. Validate stdout stream
+    await expectLater(process.stdout, emitsThrough('Processing complete.'));
+
+    // 4. Validate exit code
+    await process.shouldExit(0);
+
+    // 5. Validate filesystem mutations
+    await d.dir('project', [
+      d.file('config.json', '{"key": "value"}'),
+      d.file('output.log', 'Success')
+    ]).validate();
+  });
+}
+```
+
+## Flutter Ultra Integration
+
+Use these tools to validate the CLI app structure:
+
+- `mcp__plugin_flutter_flutter-ultra-build__analyze` — Static analysis on the CLI project
+- `mcp__plugin_flutter_flutter-ultra-build__pub_deps` — Review dependency tree
+
+---
+
+> **Attribution:** This skill is vendored from [dart-lang/skills](https://github.com/dart-lang/skills) (BSD-3-Clause).
+> Synced by `scripts/sync-upstream-skills.mjs`. Do not edit manually — changes will be overwritten on next sync.