flutter-production-builder

Flutter Production Builder

Implement Flutter from the app's actual contracts and supported platforms. Prefer Flutter/Dart capabilities and existing repository patterns before adding packages.

Trigger boundary

Use this skill for:

• implementing a Flutter feature, screen flow, data layer, platform integration, or application;
• auditing Flutter architecture and production readiness;
• choosing state, routing, network, serialization, storage, offline, and test approaches conditionally;
• preparing Android/iOS and other supported Flutter targets for release.

Do not trigger for:

• choosing Flutter versus Expo/native—use mobile-architecture-director;
• a pure Dart package with no application/platform concerns;
• visual direction alone;
• blindly replacing an established state/routing/data architecture.

Required inputs

Capture:

1. repository state, Flutter/Dart constraints, flavors, package manager state, and supported platforms/OS minimums;
2. product/design flows, adaptive behavior, accessibility and localization requirements;
3. backend/auth/data contracts, offline/sync expectations, and sensitive-data classification;
4. device/plugin/native integration requirements;
5. performance/resource targets and representative devices;
6. CI, signing, store/distribution, observability, feature flag, and rollback/update policy.

Inventory first:

python skills/flutter-production-builder/scripts/flutter_project_inventory.py . --format markdown

Safety baseline

• Inspect and preserve uncommitted work.
• Read pubspec.yaml, pubspec.lock, analysis options, generated-file conventions, platform projects, and existing architecture before edits.
• Use repository-pinned Flutter tooling where present. Do not upgrade SDK/packages under an implementation task without routing the transition to codebase-evolution-controller.
• Do not edit generated serialization/router/database/platform files directly; change authoritative input and regenerate with the repository's recorded command.
• Never place secrets in Dart source, app assets, logs, crash reports, or compile-time defines that ship to clients.
• Do not assume emulator/simulator behavior proves real-device lifecycle, biometrics, storage, performance, notification, or background behavior.