# Flutter Skill > Use for Flutter application architecture, implementation, and review, including Dart/UI/state/data work and iOS delivery concerns. Use directly for a known Flutter stack; use ios-app-development first when choosing Flutter versus native Swift or defining a mixed-stack boundary. - Skill: `bejeweledme/flutter-skill` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add bejeweledme/flutter-skill` - Raw SKILL.md: https://api.skillmd.com/api/skills/bejeweledme/flutter-skill/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: BejeweledMe (https://skillmd.com/u/bejeweledme) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/bejeweledme/flutter-skill --- # Flutter Skill Use this skill to design, review, validate, debug, implement, or release production Flutter applications, with special attention to iOS delivery. Treat Flutter as a cross-platform product stack that still has platform-specific iOS constraints: native plugins, signing, privacy, device QA, App Store review, and release operations. ## Core Rule Do not assume Flutter removes iOS work. First clarify target platforms, target iOS versions, release target, native plugins/capabilities, state/data ownership, persistence/offline needs, privacy/security constraints, performance budget, testing depth, signing/CI setup, and ownership. ## Hierarchy And Handoffs This skill owns Flutter and Dart implementation after Flutter is the selected path. Enter directly for an existing Flutter application. For a product-level platform choice, an iOS-only versus cross-platform tradeoff, or ownership across Flutter and native modules, start with `$ios-app-development`. Use `$ios-app-development` again when a plugin, entitlement, privacy, signing, or release decision crosses the Flutter/native boundary. Route native Swift, SwiftUI, UIKit, and Apple-framework implementation to `$swift-skill`; do not duplicate those details here. ## Reference Routing Read only the references needed for the current task. - Always start with `references/01-flutter-architecture.md` for broad Flutter design or review. - For iOS platform constraints, Xcode, SwiftPM, CocoaPods, deployment targets, native plugin setup, signing, TestFlight, and App Store, read `references/02-flutter-ios-platform-dependencies-release.md`. - For widgets, declarative UI, View/ViewModel boundaries, local/shared state, routing, controllers, and navigation, read `references/03-flutter-ui-state-navigation.md`. - For repositories, services, networking, source of truth, local storage, cache, offline and sync behavior, read `references/04-flutter-data-persistence-offline.md`. - For platform channels/plugins, permissions, privacy manifests, SDK signatures, Keychain/backend trust boundaries, and native iOS capabilities, read `references/05-flutter-platform-integration-security.md`. - For Dart `Future`/`Stream`/isolates, lifecycle, cancellation, performance, jank, memory, testing, debugging, crash reporting, and production checklist, read `references/06-flutter-concurrency-testing-performance.md`. ## Workflow 1. Classify the request: - New Flutter app/feature design: read `01`, `03`, `04`, then `02`, `05`, `06` as needed. - Architecture or code review: read `01`, `03`, `04`, and `06`. - Native plugin/platform work: read `02` and `05`. - Persistence/offline work: read `04`, then `06` for async/lifecycle risks. - Performance/debugging/testing: read `06`, then the relevant architecture/state/data reference. - TestFlight/App Store release: read `02`, `05`, and the release checklist in `06`. 2. Ask only for blocking details; otherwise state assumptions and proceed. 3. Keep Flutter layers explicit: UI, ViewModel/state holder, optional domain/use case, repository, service/platform adapter. 4. Validate recommendations against iOS-specific native dependencies, permissions, privacy, real-device behavior, signing/release, and observability. 5. Mark ideas not grounded in the references as `external extension`. ## Output For Design Include stack/platform assumptions, UI/state/navigation model, ViewModel/repository/service boundaries, data/source-of-truth plan, plugin/native integration plan, async/lifecycle plan, privacy/security checks, testing/observability plan, iOS release/signing plan, risks, and next steps. ## Output For Review Lead with risks: Flutter architecture gaps, business logic in widgets, state ownership problems, repository/source-of-truth gaps, plugin/native dependency risks, iOS privacy/signing blockers, performance/testing gaps, and concrete fixes. ## Fact-Check Guardrails - Say `as of Flutter 3.44` for SwiftPM default support unless current Flutter docs have been rechecked. - Do not say CocoaPods is removed or stops working. Say Flutter supports CocoaPods in maintenance/fallback mode and cite current docs. - Treat Packt examples as educational snapshots, not production authority. - Do not call an app production-ready without real-device QA, privacy checks, tests, observability, signing/release plan, and App Store/TestFlight readiness. - Do not treat `async/await` as parallel CPU execution; use isolates for CPU-heavy work. - Do not treat the mobile client as a trusted security boundary. ## Quality Bar - Prefer simple Flutter UI/data/domain boundaries before adding extra architecture. - Keep native/plugin code isolated behind services or adapters. - Represent loading, error, empty, stale and success states explicitly. - Tie performance advice to measurement on release/profile builds and real devices. - Keep recommendations scoped to the user's Flutter version, target iOS versions, plugin set, release target, and team constraints.