Skip to content
Back to skills

Flutter Widget

ASecurity

Build a Flutter widget that owns and updates local state

  • 3 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 3, 2026
ai-agentsgonode

Security analysis

A100/100

Scanned September 3, 2026

npx -y skills add black141312/ada --skill flutter-widget --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Flutter Widget?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Flutter Widget
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/black141312-flutter-widget/badge)](https://www.skillsdirectory.com/skills/black141312-flutter-widget)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: flutter-widget
description: Build a Flutter widget that owns and updates local state
category: mobile
---

# Flutter Widget

Reach for this when you need a reusable Flutter widget that holds and mutates its own state (toggles, counters, form fields, animations) rather than a pure stateless layout.

1. Decide stateless vs stateful: if nothing changes after build, use `StatelessWidget`; if the widget mutates over its lifetime, use `StatefulWidget` with a paired `State` class.
2. Declare constructor params as `final` fields and pass a `Key? key` through to `super`; mark required params `required`.
3. Put mutable values as fields on the `State` class and wrap every mutation in `setState(() { ... })` so the framework reschedules `build`.
4. Implement `build(BuildContext context)` returning the widget tree; pull colors and text styles from `Theme.of(context)` instead of hardcoding.
5. Override `initState` for one-time setup (controllers, listeners) and `dispose` to tear them down; never start work in the constructor.
6. Run `flutter analyze` and exercise the widget with a `WidgetTester` (`pumpWidget`, `tap`, `pump`) to confirm state transitions.

## Rules
- Never call `setState` in `build`, after `dispose`, or inside `initState` — it triggers loops or "called after disposed" errors.
- Always `dispose` of `AnimationController`, `TextEditingController`, `FocusNode`, and stream subscriptions.
- Keep `build` pure and cheap: no I/O, no allocations you can hoist, no side effects.
- Prefer `const` constructors and `const` child widgets to cut rebuild cost.
- For state shared across the tree, lift it up or use a state-management package instead of widget-local `setState`.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.