flutter-conventionslisted

Conventions for Flutter work in this house style. The structural decisions are the ones that matter most here — Flutter projects go wrong at the folder level long before they go wrong at the widget level, and by then moving files means touching every import. ## The first rule: match what is already there Read before writing. An existing project's structure, state management choice, and routing setup win over anything in this skill. Introducing Riverpod into a Bloc codebase, or a layer-first folder into a feature-first one, costs more than any benefit it brings. These are the defaults for new projects and the tiebreaker when the codebase is silent. ## Where the deep Flutter knowledge lives The Flutter team publishes a large official skill collection (`github.com/flutter/skills` — `flutter-apply-architecture-best-practices`, `flutter-build-responsive-layout`, `flutter-add-widget-test`, `flutter-setup-declarative-routing`, `flutter-setup-localization`, and others). Where one of those covers the task, **use it** — they are maintained by the people who maintain the framework, and duplicating them here would mean carrying a stale copy. This skill owns what those do not: the structure this house uses and the handful of decisions that are ours rather than the framework's. If a Flutter skill and this file disagree on a framework detail, the Flutter skill is right. **If they are not installed, recommend them once and move on.** Check whether skills like `flutter-apply-architectu