# Riverpod

Use when working with Flutter Riverpod state management.

- Repository: https://github.com/andrewyng/context-hub (13986 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-05-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add andrewyng/context-hub --skill riverpod -g -a claude-code -y`
Codex: `npx skills add andrewyng/context-hub --skill riverpod -g -a codex -y`
Cursor: `npx skills add andrewyng/context-hub --skill riverpod -g -a cursor -y`
Gemini CLI: `npx skills add andrewyng/context-hub --skill riverpod -g -a gemini-cli -y`

## Description

Use when working with Flutter Riverpod state management. Covers providers, consumers, refs, containers, overrides, async state, code generation, testing, and safe defaults.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Flutter Riverpod State Management

Use this skill when building Flutter state management with `riverpod` and `flutter_riverpod`.

## Core Rule

- Use `Provider` for read-only values and dependency wiring.
- Use `StateProvider` for small mutable state.
- Use `FutureProvider` for one-shot async loading.
- Use `StreamProvider` for reactive streams.
- Use `Notifier` or `AsyncNotifier` for feature state that needs mutation methods.
- Use `autoDispose` for short-lived state.
- Use `family` when provider output depends on an argument.
- Use `flutter_riverpod` in Flutter apps.
- If you use `flutter_riverpod`, you usually do not add `riverpod` separately because the Flutter package brings it in transitively.
- Current stable line is Riverpod 3.x (`riverpod` 3.2.1, `flutter_riverpod` 3.3.1).

## Decision Guide

Choose Riverpod when:
- you want provider-based dependency injection and reactive state in one model
- state should be derived from other providers
- async data is a major part of the feature
- test overrides and scoped state matter
- you want fewer classes than a Bloc-heavy approach

Choose a different pattern when:
- the feature is a tiny local state toggle and a simple widget would be enough
- the logic is better expressed as an explicit event machine

## Required Project Setup

For Dart-only code:
- add `riverpod`

For Flutter UI code:
- add `flutter_riverpod`
- wrap the app in `ProviderScope`
- use `ConsumerWidget`, `Consumer`, or `ConsumerStatefulWidget` where `ref` is needed

If code generation is used:
- add `riverpod_annotation`
- add `riverpod_generator`
- add `build_runner`

## Implementation Pattern

Prefer this structure:
- providers own state, dependencies, and derived values
- repositories and APIs stay outside widgets
- UI reads state with `ref.watch`
- UI performs imperative reads with `ref.read`
- container-level overrides are used for tests, demos, and environment-specific wiring

The rest: https://github.com/andrewyng/context-hub/blob/HEAD/content/flutter/skills/state-management/riverpod/SKILL.md