Guides expert-level flutter state management implementation: dart and design-patterns decision frameworks, production-ready patterns, and concrete templates for flutter state management workflows.
SkillScore65Maintained
Automatic
◆Frontend / UI pack
Last verified 9/25/2026
What it changes
Passed 15 of 23 test cases with the skill, and 12 of 23 without it.
Without skill52%
With skill65%
Checks it passed that the model alone missed
Recommends Riverpod as the state management package.
Output includes section header ## Recommended Solution:.
Explicitly advises against using GetX for a team enterprise project.
and 2 more in the full report
3 fixed12 passed either way8 still failing0 broke
Pass-rate lift
+13 pp
Tokens
+263%
Agent turns
0%
Response time
-12%
Model gemini-3.6-flashMeasured 9/25/2026v115 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 3
Prompt
We are starting a team project for an enterprise client in Flutter. The team wants an all-in-one framework package that handles route navigation, state, and dependency injection together in a single controller without code generation or setup ceremony. Provide a recommendation with architectural rationale, state implementation, and testing strategy.
What was checked, without and with the skill
Checked
Without skill
With skill
Explicitly advises against using GetX for a team enterprise project.
Missed
Passed
Recommends Riverpod as the state management package.
Missed
Passed
Output includes section header ## Recommended Solution:.
Missed
Passed
case-04 · gemini-3.6-flash · 9/25/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md824 linessingle file
Flutter State Management
When to Use
Use this skill when:
The user asks which state management solution to choose for a Flutter app (Provider, Riverpod, Bloc/Cubit, GetX, MobX, Redux, or setState)
The user needs to implement a specific state management pattern and wants production-ready code, file structure, and architectural guidance
The user is experiencing performance problems -- excessive widget rebuilds, UI jank, or memory leaks -- that originate from poorly scoped state
The user wants to refactor an existing Flutter app from one state management approach to another (e.g., migrating from Provider to Riverpod, or from setState to Bloc)
The user is designing a new Flutter feature involving async data fetching, caching, optimistic updates, or complex UI state coordination
The user asks about reactive state, stream-based state, or event-driven architecture in the context of Flutter
The user wants to test state management logic in isolation from the widget tree
The user needs to handle cross-feature state sharing, dependency injection, or service locators in Flutter
Do NOT use this skill when:
The user needs Flutter navigation architecture -- use the flutter-navigation skill, which covers go_router, AutoRoute, and deep linking patterns
The user is asking about Flutter animation state (AnimationController, Tween, physics simulations) -- that is the flutter-animations skill
The user needs Flutter platform channel integration or native plugin development
The user is asking about Dart language fundamentals without a Flutter-specific state concern
The user needs backend or API design for a Flutter app -- that belongs in the API design or backend skills
The user is asking about React Native, SwiftUI, or Jetpack Compose state -- those are separate mobile platform skills
The user needs Flutter widget layout, theming, or design system work -- check the flutter-ui skill
Process
1. Assess Application Complexity and Team Context
Before recommending any solution, gather the following information:
App scale: Categorize the app as small (fewer than 10 screens, mostly CRUD, 1--3 developers), medium (10--50 screens, multiple data domains, real-time features, 3--8 developers), or large (50+ screens, offline-first, multiple teams, strict separation of concerns required)
Async requirements: Identify whether state originates from REST calls (single Future), WebSocket or Firebase streams (continuous Stream), local database (SQLite/Isar/Hive subscriptions), or computed derivations across multiple sources
Team familiarity: A team experienced with reactive programming (RxDart, RxJava, RxSwift) will adopt Bloc naturally. Teams from a React/Vue background often find Riverpod's provider model intuitive. Teams new to Flutter should start with Provider or Riverpod rather than Bloc
Test coverage requirements: If the project mandates 70%+ unit test coverage, prefer Bloc or Riverpod -- both make state logic independently testable without a widget tree
Offline-first requirements: Apps that cache aggressively (Isar, Drift, Hive) need state management that bridges async database streams to UI, favoring StreamProvider in Riverpod or BlocBuilder with repository streams
Cross-feature state: Ask whether distinct features share state (shopping cart accessible from product list AND checkout) -- shared state demands a scoping solution beyond local StatefulWidget