| name | write-flutter |
| description | Write, review, or refactor idiomatic Flutter code. Use for widgets, state and architecture, lifecycle, layout, theming, accessibility, performance, and tests. Apply alongside the write-dart skill for Dart guidance. |
Write Flutter
Produce Flutter code that is composable,
correct across rebuilds, efficient, and accessible.
This skill builds on the write-dart skill:
apply that skill's Dart guidance,
then add the Flutter-specific guidance here.
In the references, DO and DON'T are near-absolute,
PREFER and AVOID are strong defaults,
and CONSIDER requires judgment.
Match the project
- Lints.
Follow the configuration in
analysis_options.yaml.
- State management.
Identify what the project already uses
such as
setState, ChangeNotifier, provider, or Riverpod,
and match its approach for shared state.
Local setState can coexist with an app-level state solution.
Don't add a second package or competing architecture for shared state
without a concrete requirement.
- Design system.
Reuse the existing theme, tokens, and spacing conventions,
whether the app is Material, Cupertino, or custom.
Core defaults
Apply these high-frequency Flutter rules alongside write-dart.
Composition
- Prefer small, single-purpose widget classes.
When a subtree has its own identity,
extract a named widget instead of a
_buildHeader() helper.
Widget classes can be const, appear by name in DevTools and error messages,
limit rebuild scope, and support independent tests.
- Give widgets
const constructors,
and use at creation sites wherever possible.
Reusing the same widget instance lets Flutter
stop the update traversal at that widget.