agentleFS
evancaevanca/flutter-ai-rules/skills/riverpod/SKILL.md

riverpod

Skill669 starsChanged 3 months agoMITView on GitHub

Use when setting up providers, combining requests, managing state disposal, passing arguments, performing side effects, or testing providers (Riverpod).

The file

Show its rules and text

We split this skill into the rules it gives an agent

25 rules. About 0 are common, 4 are distinctive, and 21 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 21

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use Provider, FutureProvider, or StreamProvider based on the return type.

    line 52
  2. Very specific:

    Use ConsumerWidget or ConsumerStatefulWidget instead of StatelessWidget/StatefulWidget when accessing providers.

    line 53
  3. Very specific:

    Never: call ref.watch inside callbacks, listeners, or Notifier methods.

    line 84
  4. Very specific:

    Use ref.read(yourNotifierProvider.notifier).method() to call Notifier methods from the UI.

    line 85
  5. Very specific:

    Check context.mounted before using ref after an await in async callbacks.

    line 86
  6. Very specific:

    Use ref.watch(asyncProvider.future) to await an async provider's resolved value.

    line 100
  7. Very specific:

    Always enable autoDispose for parameterized providers to prevent memory leaks.

    line 117
  8. Very specific:

    Use Dart 3 records or code generation for multiple parameters — they naturally override ==.

    line 118
  9. Very specific:

    Avoid passing plain List or Map as parameters (no == override).

    line 119
  10. Very specific:

    Use the provider_parameters lint rule from riverpod_lint to catch equality mistakes.

    line 120
  11. Very specific:

    Use ref.onDispose for cleanup.

    line 138
  12. Very specific:

    Use ref.invalidate(provider) to force destruction.

    line 139
  13. Very specific:

    Use ref.refresh(provider) to invalidate and immediately read the new value — always use the return value.

    line 140
  14. Very specific:

    Place eager initialization in a public widget (not main()) for consistent test behavior.

    line 158
  15. Very specific:

    Use AsyncValue.requireValue to read data directly and throw clearly if not ready.

    line 159
  16. Very specific:

    Use ref.read (not ref.watch) in event handlers.

    line 184
  17. Very specific:

    After a side effect, update state by: setting it directly, calling ref.invalidateSelf(), or manually updating the cache.

    line 185
  18. Distinctive:

    Always handle loading and error states in the UI.

    line 186
  19. Distinctive:

    Do not perform side effects in provider constructors or build methods.

    line 187
  20. Very specific:

    Create a new ProviderContainer or ProviderScope for each test — never share state between tests.

    line 231
  21. Very specific:

    Use container.listen over container.read for autoDispose providers to keep state alive during the test.

    line 232
  22. Very specific:

    Use overrides to inject mocks or fakes.

    line 233
  23. Distinctive:

    Prefer mocking dependencies (repositories) rather than Notifiers directly.

    line 234
  24. Very specific:

    If you must mock a Notifier, subclass the original — don't use implements or with Mock.

    line 235
  25. Distinctive:

    Place Notifier mocks in the same file as the Notifier if using code generation.

    line 236

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Riverpod Skill

This skill defines how to correctly use Riverpod for state management in Flutter and Dart applications.


1. Setup

void main() {
  runApp(const ProviderScope(child: MyApp()));
}
  • Wrap your app with ProviderScope directly in runApp — never inside MyApp.
  • Install and use riverpod_lint to enable IDE refactoring and enforce best practices.

2. Defining Providers

// Functional provider (codegen)
@riverpod
int example(Ref ref) => 0;

// FutureProvider (codegen)
@riverpod
Future<List<Todo>> todos(Ref ref) async {
  return ref.watch(repositoryProvider).fetchTodos();
}

// Notifier (codegen)
@riverpod
class TodosNotifier extends _$TodosNotifier {
  @override
  Future<List<Todo>> build() async {
    return ref.watch(repositoryProvider).fetchTodos();
  }

  Future<void> addTodo(Todo todo) async { ... }
}
  • Define all providers as final top-level variables.
  • Use Provider, FutureProvider, or StreamProvider based on the return type.
  • Use ConsumerWidget or ConsumerStatefulWidget instead of StatelessWidget/StatefulWidget when accessing providers.

3. Using Ref

MethodUse for
ref.watchReactively listen — rebuilds when value changes. Use during build phase only.
ref.readOne-time access — use in callbacks/Notifier methods, not in build.
ref.listenImperative subscription — prefer ref.watch where possible.
ref.onDisposeCleanup when provider state is destroyed.
// In a widget
class MyWidget extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final value = ref.watch(myProvider);
    return Text('$value');
  }
}

// Cleanup in a provider
final provider = StreamProvider<int>((ref) {
  final controller = StreamController<int>();
  ref.onDispose(controller.close);
  return controller.stream;
});
  • Never call ref.watch inside callbacks, listeners, or Notifier methods.
  • Use ref.read(yourNotifierProvider.notifier).method() to call Notifier methods from the UI.
  • Check context.mounted before using ref after an await in async callbacks.

4. Combining Providers

@riverpod
Future<String> userGreeting(Ref ref) async {
  final user = await ref.watch(userProvider.future);
  return 'Hello, ${user.name}!';
}
  • Use ref.watch(asyncProvider.future) to await an async provider's resolved value.
  • Providers only execute once and cache the result — multiple widgets listening to the same provider share one computation.

5. Passing Arguments (Families)

@riverpod
Future<Todo> todo(Ref ref, String id) async {
  return ref.watch(repositoryProvider).fetchTodo(id);
}

// Usage
final todo = ref.watch(todoProvider('some-id'));
  • Always enable autoDispose for parameterized providers to prevent memory leaks.
  • Use Dart 3 records or code generation for multiple parameters — they naturally override ==.
  • Avoid passing plain List or Map as parameters (no == override); use const collections, records, or classes with proper equality.
  • Use the provider_parameters lint rule from riverpod_lint to catch equality mistakes.

6. Auto Dispose & State Lifecycle

  • With codegen: state is destroyed by default when no longer listened to. Opt out with keepAlive: true.
  • Without codegen: state is kept alive by default. Use .autoDispose to enable disposal.
  • State is always destroyed when a provider is recomputed.
// keepAlive with timer
ref.onCancel(() {
  final link = ref.keepAlive();
  Timer(const Duration(minutes: 5), link.close);
});
  • Use ref.onDispose for cleanup; do not trigger side effects or modify providers inside it.
  • Use ref.invalidate(provider) to force destruction; use ref.invalidateSelf() from within the provider.
  • Use ref.refresh(provider) to invalidate and immediately read the new value — always use the return value.

7. Eager Initialization

Providers are lazy by default. To eagerly initialize:

// In MyApp or a dedicated widget under ProviderScope:
Consumer(
  builder: (context, ref, _) {
    ref.watch(myEagerProvider); // forces initialization
    return const MyApp();
  },
)
  • Place eager initialization in a public widget (not main()) for consistent test behavior.
  • Use AsyncValue.requireValue to read data directly and throw clearly if not ready.

8. Performing Side Effects

@riverpod
class TodosNotifier extends _$TodosNotifier {
  Future<void> addTodo(Todo todo) async {
    state = const AsyncLoading();
    state = await AsyncValue.guard(() async {
      await ref.read(repositoryProvider).addTodo(todo);
      return [...?state.value, todo];
    });
  }
}

// In UI:
ElevatedButton(
  onPressed: () => ref.read(todosNotifierProvider.notifier).addTodo(todo),
  child: const Text('Add'),
)
  • Use ref.read (not ref.watch) in event handlers.
  • After a side effect, update state by: setting it directly, calling ref.invalidateSelf(), or manually updating the cache.
  • Always handle loading and error states in the UI.
  • Do not perform side effects in provider constructors or build methods.

9. Provider Observers

class MyObserver extends ProviderObserver {
  @override
  void didUpdateProvider(ProviderObserverContext context, Object? previousValue, Object? newValue) {
    print('[${context.provider}] updated: $previousValue → $newValue');
  }

  @override
  void providerDidFail(ProviderObserverContext context, Object error, StackTrace stackTrace) {
    // Report to error service
  }
}

runApp(ProviderScope(observers: [MyObserver()], child: MyApp()));

10. Testing

// Unit test
final container = ProviderContainer(
  overrides: [repositoryProvider.overrideWith((_) => FakeRepository())],
);
addTearDown(container.dispose);

expect(await container.read(todosProvider.future), isNotEmpty);

// Widget test
await tester.pumpWidget(
  ProviderScope(
    overrides: [repositoryProvider.overrideWith((_) => FakeRepository())],
    child: const MyApp(),
  ),
);
  • Create a new ProviderContainer or ProviderScope for each test — never share state between tests.
  • Use container.listen over container.read for autoDispose providers to keep state alive during the test.
  • Use overrides to inject mocks or fakes.
  • Prefer mocking dependencies (repositories) rather than Notifiers directly.
  • If you must mock a Notifier, subclass the original — don't use implements or with Mock.
  • Place Notifier mocks in the same file as the Notifier if using code generation.
  • Obtain the container in widget tests with ProviderScope.containerOf(tester.element(...)).

References

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.