reis-mobile 0.3.5

package/skills/flutter-animating-apps/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: flutter-animating-apps
+description: Implements animated effects, transitions, and motion in a Flutter app. Use when adding visual feedback, shared element transitions, or physics-based animations.
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Thu, 12 Mar 2026 22:16:34 GMT
+routing: manual
+stacks: [flutter]
+source: https://github.com/flutter/skills
+license: BSD-3-Clause
+---
+# Implementing Flutter Animations
+
+## Contents
+- [Core Concepts](#core-concepts)
+- [Animation Strategies](#animation-strategies)
+- [Workflows](#workflows)
+  - [Implementing Implicit Animations](#implementing-implicit-animations)
+  - [Implementing Explicit Animations](#implementing-explicit-animations)
+  - [Implementing Hero Transitions](#implementing-hero-transitions)
+  - [Implementing Physics-Based Animations](#implementing-physics-based-animations)
+- [Examples](#examples)
+
+## Core Concepts
+
+Manage Flutter animations using the core typed `Animation` system. Do not manually calculate frames; rely on the framework's ticker and interpolation classes.
+
+*   **`Animation<T>`**: Treat this as an abstract representation of a value that changes over time. It holds state (completed, dismissed) and notifies listeners, but knows nothing about the UI.
+*   **`AnimationController`**: Instantiate this to drive the animation. It generates values (typically 0.0 to 1.0) tied to the screen refresh rate. Always provide a `vsync` (usually via `SingleTickerProviderStateMixin`) to prevent offscreen resource consumption. Always `dispose()` controllers to prevent memory leaks.
+*   **`Tween<T>`**: Define a stateless mapping from an input range (usually 0.0-1.0) to an output type (e.g., `Color`, `Offset`, `double`). Chain tweens with curves using `.animate()`.
+*   **`Curve`**: Apply non-linear timing (e.g., `Curves.easeIn`, `Curves.bounceOut`) to an animation using a `CurvedAnimation` or `CurveTween`.
+
+## Animation Strategies
+
+Apply conditional logic to select the correct animation approach:
+
+*   **If animating simple property changes (size, color, opacity) without playback control:** Use **Implicit Animations** (e.g., `AnimatedContainer`, `AnimatedOpacity`, `TweenAnimationBuilder`).
+*   **If requiring playback control (play, pause, reverse, loop) or coordinating multiple properties:** Use **Explicit Animations** (e.g., `AnimationController` with `AnimatedBuilder` or `AnimatedWidget`).
+*   **If animating elements between two distinct routes:** Use **Hero Animations** (Shared Element Transitions).
+*   **If modeling real-world motion (e.g., snapping back after a drag):** Use **Physics-Based Animations** (e.g., `SpringSimulation`).
+*   **If animating a sequence of overlapping or delayed motions:** Use **Staggered Animations** (multiple `Tween`s driven by a single `AnimationController` using `Interval` curves).
+
+## Workflows
+
+### Implementing Implicit Animations
+
+Use this workflow for "fire-and-forget" state-driven animations.
+
+- [ ] **Task Progress:**
+  - [ ] Identify the target properties to animate (e.g., width, color).
+  - [ ] Replace the static widget (e.g., `Container`) with its animated counterpart (e.g., `AnimatedContainer`).
+  - [ ] Define the `duration` property.
+  - [ ] (Optional) Define the `curve` property for non-linear motion.
+  - [ ] Trigger the animation by updating the properties inside a `setState()` call.
+  - [ ] Run validator -> review UI for jank -> adjust duration/curve if necessary.
+
+### Implementing Explicit Animations
+
+Use this workflow when you need granular control over the animation lifecycle.
+
+- [ ] **Task Progress:**
+  - [ ] Add `SingleTickerProviderStateMixin` (or `TickerProviderStateMixin` for multiple controllers) to the `State` class.
+  - [ ] Initialize an `AnimationController` in `initState()`, providing `vsync: this` and a `duration`.
+  - [ ] Define a `Tween` and chain it to the controller using `.animate()`.
+  - [ ] Wrap the target UI in an `AnimatedBuilder` (preferred for complex trees) or subclass `AnimatedWidget`.
+  - [ ] Pass the `Animation` object to the `AnimatedBuilder`'s `animation` property.
+  - [ ] Control playback using `controller.forward()`, `controller.reverse()`, or `controller.repeat()`.
+  - [ ] Call `controller.dispose()` in the `dispose()` method.
+  - [ ] Run validator -> check for memory leaks -> ensure `dispose()` is called.
+
+### Implementing Hero Transitions
+
+Use this workflow to fly a widget between two routes.
+
+- [ ] **Task Progress:**
+  - [ ] Wrap the source widget in a `Hero` widget.
+  - [ ] Assign a unique, data-driven `tag` to the source `Hero`.
+  - [ ] Wrap the destination widget in a `Hero` widget.
+  - [ ] Assign the *exact same* `tag` to the destination `Hero`.
+  - [ ] Ensure the widget trees inside both `Hero` widgets are visually similar to prevent jarring jumps.
+  - [ ] Trigger the transition by pushing the destination route via `Navigator`.
+
+### Implementing Physics-Based Animations
+
+Use this workflow for gesture-driven, natural motion.
+
+- [ ] **Task Progress:**
+  - [ ] Set up an `AnimationController` (do not set a fixed duration).
+  - [ ] Capture gesture velocity using a `GestureDetector` (e.g., `onPanEnd` providing `DragEndDetails`).
+  - [ ] Convert the pixel velocity to the coordinate space of the animating property.
+  - [ ] Instantiate a `SpringSimulation` with mass, stiffness, damping, and the calculated velocity.
+  - [ ] Drive the controller using `controller.animateWith(simulation)`.
+
+## Examples
+
+<details>
+<summary><b>Example: Explicit Animation (Staggered with AnimatedBuilder)</b></summary>
+
+```dart
+class StaggeredAnimationDemo extends StatefulWidget {
+  @override
+  State<StaggeredAnimationDemo> createState() => _StaggeredAnimationDemoState();
+}
+
+class _StaggeredAnimationDemoState extends State<StaggeredAnimationDemo> with SingleTickerProviderStateMixin {
+  late AnimationController _controller;
+  late Animation<double> _widthAnimation;
+  late Animation<Color?> _colorAnimation;
+
+  @override
+  void initState() {
+    super.initState();
+    _controller = AnimationController(
+      duration: const Duration(seconds: 2),
+      vsync: this,
+    );
+
+    // Staggered width animation (0.0 to 0.5 interval)
+    _widthAnimation = Tween<double>(begin: 50.0, end: 200.0).animate(
+      CurvedAnimation(
+        parent: _controller,
+        curve: const Interval(0.0, 0.5, curve: Curves.easeIn),
+      ),
+    );
+
+    // Staggered color animation (0.5 to 1.0 interval)
+    _colorAnimation = ColorTween(begin: Colors.blue, end: Colors.red).animate(
+      CurvedAnimation(
+        parent: _controller,
+        curve: const Interval(0.5, 1.0, curve: Curves.easeOut),
+      ),
+    );
+
+    _controller.forward();
+  }
+
+  @override
+  void dispose() {
+    _controller.dispose(); // CRITICAL: Prevent memory leaks
+    super.dispose();
+  }
+
+  @override
+  Widget build(BuildContext context) {
+    return AnimatedBuilder(
+      animation: _controller,
+      builder: (context, child) {
+        return Container(
+          width: _widthAnimation.value,
+          height: 50.0,
+          color: _colorAnimation.value,
+        );
+      },
+    );
+  }
+}
+```
+</details>
+
+<details>
+<summary><b>Example: Custom Page Route Transition</b></summary>
+
+```dart
+Route createCustomRoute(Widget destination) {
+  return PageRouteBuilder(
+    pageBuilder: (context, animation, secondaryAnimation) => destination,
+    transitionsBuilder: (context, animation, secondaryAnimation, child) {
+      const begin = Offset(0.0, 1.0); // Start from bottom
+      const end = Offset.zero;
+      const curve = Curves.easeOut;
+
+      final tween = Tween(begin: begin, end: end).chain(CurveTween(curve: curve));
+      final offsetAnimation = animation.drive(tween);
+
+      return SlideTransition(
+        position: offsetAnimation,
+        child: child,
+      );
+    },
+  );
+}
+
+// Usage: Navigator.of(context).push(createCustomRoute(const NextPage()));
+```
+</details>

package/skills/flutter-app-architecture/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: flutter-app-architecture
+description: Provides best practices for Flutter app architecture, including layered architecture, data flow, state management patterns, and extensibility guidelines.
+intents: [architecture]
+stacks: [flutter]
+source: https://github.com/evanca/flutter-ai-rules
+license: MIT
+---
+
+# Flutter App Architecture Skill
+
+This skill provides comprehensive guidelines for structuring Flutter applications using layered architecture, proper data flow, and best practices for maintainability and testability.
+
+---
+
+## Architecture
+
+1. Separate your features into a UI Layer (presentation), a Data Layer (business data and logic), and, for complex apps, consider adding a Domain (Logic) Layer between UI and Data layers to encapsulate business logic and use-cases.
+2. You can organize code by feature: The classes needed for each feature are grouped together. For example, you might have an auth directory, which would contain files like auth_viewmodel.dart (or, depending on your state management approach: auth_controller.dart, auth_provider.dart, auth_bloc.dart), login_usecase.dart, logout_usecase.dart, login_screen.dart, logout_button.dart, etc. Alternatively, you can organize by type or use a hybrid approach.
+3. Only allow communication between adjacent layers; the UI layer should not access the data layer directly, and vice versa.
+4. Introduce a Logic (Domain) Layer only for complex business logic that does not fit cleanly in the UI or Data layers.
+5. Clearly define the responsibilities, boundaries, and interfaces of each layer and component (Views, View Models, Repositories, Services).
+6. Further divide each layer into components with specific responsibilities and well-defined interfaces.
+7. In the UI Layer, use Views to describe how to present data to the user; keep logic minimal and only UI-related.
+8. Pass events from Views to View Models in response to user interactions.
+9. In View Models, contain logic to convert app data into UI state and maintain the current state needed by the view.
+10. Expose callbacks (commands) from View Models to Views and retrieve/transform data from repositories.
+11. In the Data Layer, use Repositories as the single source of truth (SSOT) for model data and to handle business logic such as caching, error handling, and refreshing data.
+12. Only the SSOT class (usually the repository) should be able to mutate its data; all other classes should read from it.
+13. Repositories should transform raw data from services into domain models and output data consumed by View Models.
+14. Use Services to wrap API endpoints and expose asynchronous response objects; services should isolate data-loading and hold no state.
+15. Use dependency injection to provide components with their dependencies, enabling testability and flexibility.
+
+## Data Flow and State
+
+1. Follow unidirectional data flow: state flows from the data layer through the logic layer to the UI layer, and events from user interaction flow in the opposite direction.
+2. Data changes should always happen in the SSOT (data layer), not in the UI or logic layers.
+3. The UI should always reflect the current (immutable) state; trigger UI rebuilds only in response to state changes.
+4. Views should contain as little logic as possible and be driven by state from View Models.
+
+## Use Cases / Interactors
+
+1. Introduce use cases/interactors in the domain layer only when logic is complex, reused, or merges data from multiple repositories.
+2. Use cases depend on repositories and may be used by multiple view models.
+3. Add use cases only when needed; refactor to use use-cases exclusively if logic is repeatedly shared across view models.
+
+## Extensibility and Testability
+
+1. All architectural components should have well-defined inputs and outputs (interfaces).
+2. Favor dependency injection to allow swapping implementations without changing consumers.
+3. Test view models by mocking repositories; test UI logic independently of widgets.
+4. Design components to be easily replaceable and independently testable.
+
+## Best Practices
+
+1. Strongly recommend following separation of concerns and layered architecture.
+2. Strongly recommend using dependency injection for testability and flexibility.
+3. Recommend using MVVM as the default pattern, but adapt as needed for your app's complexity.
+4. Use key-value storage for simple data (e.g., configuration, preferences) and SQL storage for complex relationships.
+5. Use optimistic updates to improve perceived responsiveness by updating the UI before operations complete.
+6. Support offline-first strategies by combining local and remote data sources in repositories and enabling synchronization as appropriate.
+7. Keep views focused on presentation and extract reusable widgets into separate components.
+8. Use `StatelessWidget` when possible and avoid unnecessary `StatefulWidget`s.
+9. Keep build methods simple and focused on rendering.
+10. Choose state management approaches appropriate to the complexity of your app.
+11. Keep state as local as possible to minimize rebuilds and complexity.
+12. Use `const` constructors when possible to improve performance.
+13. Avoid expensive operations in build methods and implement pagination for large lists.
+14. Keep files focused on a single responsibility and limit file length for readability.
+15. Group related functionality together and use `final` for fields and top-level variables when possible.
+16. Prefer making declarations private and consider making constructors `const` if the class supports it.
+17. Follow Dart naming conventions and format code using `dart format`.
+18. Use curly braces for all flow control statements to ensure clarity and prevent bugs.
+19. Prefer explicit typing and generics on public APIs (for example, prefer typed command signatures such as `Command0<void>` rather than untyped/dynamic signatures) to improve clarity and type safety.
+20. For small immutable domain or data models, prefer using `abstract class` with `const` constructors and `final` fields where it improves readability and enforces immutability.
+21. Use descriptive constant names for resources and table identifiers (for example prefer `_todoTableName` over compact prefixes like `_kTableTodo`) to improve clarity across examples and migrations.
+
+## References
+
+- [Flutter Website GitHub Repository](https://github.com/flutter/website)

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

@@ -0,0 +1,166 @@
+---
+name: flutter-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.
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Tue, 21 Apr 2026 20:11:20 GMT
+intents: [architecture]
+stacks: [flutter]
+source: https://github.com/flutter/skills
+license: BSD-3-Clause
+---
+# 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'),
+            ),
+          ],
+        );
+      },
+    );
+  }
+}
+```

package/skills/flutter-build-responsive-layout/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: flutter-build-responsive-layout
+description: Use `LayoutBuilder`, `MediaQuery`, or `Expanded/Flexible` to create a layout that adapts to different screen sizes. Use when you need the UI to look good on both mobile and tablet/desktop form factors.
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Tue, 21 Apr 2026 20:17:40 GMT
+routing: manual
+stacks: [flutter]
+source: https://github.com/flutter/skills
+license: BSD-3-Clause
+---
+# Implementing Adaptive Layouts
+
+## Contents
+- [Space Measurement Guidelines](#space-measurement-guidelines)
+- [Widget Sizing and Constraints](#widget-sizing-and-constraints)
+- [Device and Orientation Behaviors](#device-and-orientation-behaviors)
+- [Workflow: Constructing an Adaptive Layout](#workflow-constructing-an-adaptive-layout)
+- [Workflow: Optimizing for Large Screens](#workflow-optimizing-for-large-screens)
+- [Examples](#examples)
+
+## Space Measurement Guidelines
+Determine the available space accurately to ensure layouts adapt to the app window, not just the physical device.
+
+*   **Use `MediaQuery.sizeOf(context)`** to get the size of the entire app window.
+*   **Use `LayoutBuilder`** to make layout decisions based on the parent widget's allocated space. Evaluate `constraints.maxWidth` to determine the appropriate widget tree to return.
+*   **Do not use `MediaQuery.orientationOf` or `OrientationBuilder`** near the top of the widget tree to switch layouts. Device orientation does not accurately reflect the available app window space.
+*   **Do not check for hardware types** (e.g., "phone" vs. "tablet"). Flutter apps run in resizable windows, multi-window modes, and picture-in-picture. Base all layout decisions strictly on available window space.
+
+## Widget Sizing and Constraints
+Understand and apply Flutter's core layout rule: **Constraints go down. Sizes go up. Parent sets position.**
+
+*   **Distribute Space:** Use `Expanded` and `Flexible` within `Row`, `Column`, or `Flex` widgets.
+    *   Use `Expanded` to force a child to fill all remaining available space (equivalent to `Flexible` with `fit: FlexFit.tight` and a `flex` factor of 1.0).
+    *   Use `Flexible` to allow a child to size itself up to a specific limit while still expanding/contracting. Use the `flex` factor to define the ratio of space consumption among siblings.
+*   **Constrain Width:** Prevent widgets from consuming all horizontal space on large screens. Wrap widgets like `GridView` or `ListView` in a `ConstrainedBox` or `Container` and define a `maxWidth` in the `BoxConstraints`.
+*   **Lazy Rendering:** Always use `ListView.builder` or `GridView.builder` when rendering lists with an unknown or large number of items.
+
+## Device and Orientation Behaviors
+Ensure the app behaves correctly across all device form factors and input methods.
+
+*   **Do not lock screen orientation.** Locking orientation causes severe layout issues on foldable devices, often resulting in letterboxing (the app centered with black borders). Android large format tiers require both portrait and landscape support.
+*   **Fallback for Locked Orientation:** If business requirements strictly mandate a locked orientation, use the `Display API` to retrieve physical screen dimensions instead of `MediaQuery`. `MediaQuery` fails to receive the larger window size in compatibility modes.
+*   **Support Multiple Inputs:** Implement support for basic mice, trackpads, and keyboard shortcuts. Ensure touch targets are appropriately sized and keyboard navigation is accessible.
+
+## Workflow: Constructing an Adaptive Layout
+
+Follow this workflow to implement a layout that adapts to the available `BoxConstraints`.
+
+**Task Progress:**
+- [ ] Identify the target widget that requires adaptive behavior.
+- [ ] Wrap the widget tree in a `LayoutBuilder`.
+- [ ] Extract the `constraints.maxWidth` from the builder callback.
+- [ ] Define an adaptive breakpoint (e.g., `largeScreenMinWidth = 600`).
+- [ ] **If `maxWidth > largeScreenMinWidth`:** Return a large-screen layout (e.g., a `Row` placing a navigation sidebar and content area side-by-side).
+- [ ] **If `maxWidth <= largeScreenMinWidth`:** Return a small-screen layout (e.g., a `Column` or standard navigation-style approach).
+- [ ] Run validator -> resize the application window -> review layout transitions -> fix overflow errors.
+
+## Workflow: Optimizing for Large Screens
+
+Follow this workflow to prevent UI elements from stretching unnaturally on large displays.
+
+**Task Progress:**
+- [ ] Identify full-width components (e.g., `ListView`, text blocks, forms).
+- [ ] **If optimizing a list:** Convert `ListView.builder` to `GridView.builder` using `SliverGridDelegateWithMaxCrossAxisExtent` to automatically adjust column counts based on window size.
+- [ ] **If optimizing a form or text block:** Wrap the component in a `ConstrainedBox`.
+- [ ] Apply `BoxConstraints(maxWidth: [optimal_width])` to the `ConstrainedBox`.
+- [ ] Wrap the `ConstrainedBox` in a `Center` widget to keep the constrained content centered on large screens.
+- [ ] Run validator -> test on desktop/tablet target -> review horizontal stretching -> adjust `maxWidth` or grid extents.
+
+## Examples
+
+### Adaptive Layout using LayoutBuilder
+Demonstrates switching between a mobile and desktop layout based on available width.
+
+```dart
+import 'package:flutter/material.dart';
+
+const double largeScreenMinWidth = 600.0;
+
+class AdaptiveLayout extends StatelessWidget {
+  const AdaptiveLayout({super.key});
+
+  @override
+  Widget build(BuildContext context) {
+    return LayoutBuilder(
+      builder: (context, constraints) {
+        if (constraints.maxWidth > largeScreenMinWidth) {
+          return _buildLargeScreenLayout();
+        } else {
+          return _buildSmallScreenLayout();
+        }
+      },
+    );
+  }
+
+  Widget _buildLargeScreenLayout() {
+    return Row(
+      children: [
+        const SizedBox(width: 250, child: Placeholder(color: Colors.blue)),
+        const VerticalDivider(width: 1),
+        Expanded(child: const Placeholder(color: Colors.green)),
+      ],
+    );
+  }
+
+  Widget _buildSmallScreenLayout() {
+    return const Placeholder(color: Colors.green);
+  }
+}
+```
+
+### Constraining Width on Large Screens
+Demonstrates preventing a widget from consuming all horizontal space.
+
+```dart
+import 'package:flutter/material.dart';
+
+class ConstrainedContent extends StatelessWidget {
+  const ConstrainedContent({super.key});
+
+  @override
+  Widget build(BuildContext context) {
+    return Scaffold(
+      body: Center(
+        child: ConstrainedBox(
+          constraints: const BoxConstraints(
+            maxWidth: 800.0, // Maximum width for readability
+          ),
+          child: ListView.builder(
+            itemCount: 50,
+            itemBuilder: (context, index) {
+              return ListTile(
+                title: Text('Item $index'),
+              );
+            },
+          ),
+        ),
+      ),
+    );
+  }
+}
+```