Install
$ agentstack add skill-serverpod-skills-registry-riverpod-containers ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Riverpod — Containers / Scopes
Instructions
Providers themselves hold no state. State is stored in a ProviderContainer. In Flutter you use the ProviderScope widget, which creates and exposes a container to the widget tree.
Flutter: ProviderScope
Wrap your app at the root so widgets can read providers:
void main() {
runApp(
ProviderScope(
child: MyApp(),
),
);
}
After that, use Consumer / ConsumerWidget / ConsumerStatefulWidget to get a ref and call ref.watch / ref.read. You can also pass overrides or observers to ProviderScope.
Pure Dart: ProviderContainer
In command-line or server-side Dart, create a container, use it, then dispose it:
void main() {
final container = ProviderContainer();
try {
final sub = container.listen(counterProvider, (previous, next) {
print('Counter changed from $previous to $next');
});
print('Counter starts at ${sub.read()}');
} finally {
container.dispose();
}
}
Why state lives in a container
- Separation of concerns — Only the provider (and ref) can change its state; the UI typically calls notifier methods.
- Testing — Each test can create a new container (e.g.
ProviderContainer.test()) for a fresh state; no shared global state. - Configuration — Overrides and observers are set on the container/scope. See riverpod-overrides and riverpod-observers.
- Scoping — The same provider can resolve to different state in different parts of the tree (advanced). See riverpod-scoping.
Testing
Do not use ProviderContainer() directly in tests. Use ProviderContainer.test() so the container is disposed when the test ends:
test('Counter starts at 0 and can be incremented', () {
final container = ProviderContainer.test();
expect(container.read(counterProvider), 0);
container.read(counterProvider.notifier).increment();
expect(container.read(counterProvider), 1);
});
In widget tests, wrap the widget in ProviderScope and use tester.container() to get the container if needed (see riverpod-testing).
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: serverpod
- Source: serverpod/skills-registry
- License: BSD-3-Clause
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.