Mobile Flutter Orchestrator
The single entry skill for Flutter/Dart (and Android/KMP) work. It locates the task on the
layer × phase map — UI / state / data / build, then write → review — and delegates to one
of the specialist spokes. The cross-cutting decision every app turns on (which state-management
solution, and the immutable-state contract it implies) plus the shared conventions live in
mobile-flutter-core; read it before picking a state library or wiring the data layer.
Cluster map (spoke → role)
dart-flutter-patterns — copy-paste-ready Dart 3 / Flutter patterns: null safety, sealed/immutable state, async composition, widget architecture, BLoC + Riverpod, GoRouter, Dio, Freezed, testing. The "how do I write this" reference.flutter-dart-code-review — library-agnostic review checklist across 15 axes (widgets, state, performance, a11y, security, l10n, DI, static analysis). The "is this code right" gate.android-clean-architecture — module boundaries and dependency rules for Android/KMP (domain → data → presentation), UseCases, Repositories, Room/SQLDelight/Ktor, Koin/Hilt. The "how is the project structured" reference for native + multiplatform.mobile-flutter-core (shared model) — the state-management decision matrix, immutable-state contract, layering rule, and version/tooling matrix all spokes share.
Routing rules by intent
Write / implement a feature
- Idiomatic Dart/Flutter code (state, nav, networking, codegen) →
dart-flutter-patterns
- Choosing/contrasting state solutions before you start →
mobile-flutter-core (decision matrix), then dart-flutter-patterns
- Native Android or Kotlin-Multiplatform module/data layer →
android-clean-architecture
Structure / architect
- Where does this code live? Module + dependency direction →
android-clean-architecture (native/KMP) or the clean-architecture + widget-architecture sections of dart-flutter-patterns (Flutter UI)
- The layering rule that applies to both →
mobile-flutter-core
Review / harden
- PR review, audit, "find what's wrong" →
flutter-dart-code-review
- Security/perf/a11y pass before ship →
flutter-dart-code-review (sections 5, 7, 9)
Cross-cutting decision
- "Which state library / what's the immutable contract / what versions" →
mobile-flutter-core
Standard flow
- Locate the task: which layer (UI → state → data → build) and which phase (write vs review).
- If it touches state management or the data/domain boundary, pull the decision from
mobile-flutter-core first — the state choice constrains immutability, testing, and rebuild discipline downstream.
- Delegate to the spoke(s). Multi-step asks fan out in layer order (e.g. "build this feature properly" →
mobile-flutter-core decision → android-clean-architecture / dart-flutter-patterns to implement → flutter-dart-code-review to verify).
- Return: chosen spoke(s), the state/architecture decision implied, target platform (Flutter / Android / KMP), and the next action.
Guardrails
See mobile-flutter-core. In short: business logic never lives in widgets — it sits in a
state container behind injected dependencies, with a repository abstracting data sources. Model
mutually-exclusive states as sealed/union types, not boolean flags. Keep domain pure (no
framework imports). Always mounted-check a BuildContext after an await. Pick one
state-management solution and one routing approach per app and stay consistent — the cluster's
value is a coherent architecture, not a mix of every pattern at once.
Loading spokes on demand
To keep CLI startup context lean, this cluster's spokes are not separately registered as skills — only this orchestrator and its *-core are enumerated. When you route to a spoke named above, load it on demand by reading its file:
~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md (or skills/<spoke-name>/SKILL.md inside the skill-clusters repo).
1---2name: mobile-flutter-orchestrator3description: Route a Flutter/Dart (and Android/KMP) task to the right specialist — idiomatic patterns, the state-management decision, navigation/networking/codegen wiring, clean-architecture module boundaries, and the review/ship checklist. USE WHEN building, structuring, reviewing, or hardening a Flutter or Kotlin-Multiplatform mobile app but the specific concern hasn't been named.4---56# Mobile Flutter Orchestrator78The single entry skill for Flutter/Dart (and Android/KMP) work. It locates the task on the9**layer × phase** map — UI / state / data / build, then write → review — and delegates to one10of the specialist spokes. The cross-cutting decision every app turns on (which state-management11solution, and the immutable-state contract it implies) plus the shared conventions live in12`mobile-flutter-core`; read it before picking a state library or wiring the data layer.1314## Cluster map (spoke → role)1516- **`dart-flutter-patterns`** — copy-paste-ready Dart 3 / Flutter patterns: null safety, sealed/immutable state, async composition, widget architecture, BLoC + Riverpod, GoRouter, Dio, Freezed, testing. The "how do I write this" reference.17- **`flutter-dart-code-review`** — library-agnostic review checklist across 15 axes (widgets, state, performance, a11y, security, l10n, DI, static analysis). The "is this code right" gate.18- **`android-clean-architecture`** — module boundaries and dependency rules for Android/KMP (domain → data → presentation), UseCases, Repositories, Room/SQLDelight/Ktor, Koin/Hilt. The "how is the project structured" reference for native + multiplatform.19- **`mobile-flutter-core`** *(shared model)* — the state-management decision matrix, immutable-state contract, layering rule, and version/tooling matrix all spokes share.2021## Routing rules by intent2223**Write / implement a feature**24- Idiomatic Dart/Flutter code (state, nav, networking, codegen) → `dart-flutter-patterns`25- Choosing/contrasting state solutions before you start → `mobile-flutter-core` (decision matrix), then `dart-flutter-patterns`26- Native Android or Kotlin-Multiplatform module/data layer → `android-clean-architecture`2728**Structure / architect**29- Where does this code live? Module + dependency direction → `android-clean-architecture` (native/KMP) or the clean-architecture + widget-architecture sections of `dart-flutter-patterns` (Flutter UI)30- The layering rule that applies to both → `mobile-flutter-core`3132**Review / harden**33- PR review, audit, "find what's wrong" → `flutter-dart-code-review`34- Security/perf/a11y pass before ship → `flutter-dart-code-review` (sections 5, 7, 9)3536**Cross-cutting decision**37- "Which state library / what's the immutable contract / what versions" → `mobile-flutter-core`3839## Standard flow40411. Locate the task: which **layer** (UI → state → data → build) and which **phase** (write vs review).422. If it touches **state management or the data/domain boundary**, pull the decision from `mobile-flutter-core` first — the state choice constrains immutability, testing, and rebuild discipline downstream.433. Delegate to the spoke(s). Multi-step asks fan out in layer order (e.g. "build this feature properly" → `mobile-flutter-core` decision → `android-clean-architecture` / `dart-flutter-patterns` to implement → `flutter-dart-code-review` to verify).444. Return: chosen spoke(s), the state/architecture decision implied, target platform (Flutter / Android / KMP), and the next action.4546## Guardrails4748See `mobile-flutter-core`. In short: **business logic never lives in widgets** — it sits in a49state container behind injected dependencies, with a repository abstracting data sources. Model50mutually-exclusive states as sealed/union types, not boolean flags. Keep `domain` pure (no51framework imports). Always `mounted`-check a `BuildContext` after an `await`. Pick **one**52state-management solution and one routing approach per app and stay consistent — the cluster's53value is a coherent architecture, not a mix of every pattern at once.5455## Loading spokes on demand5657To keep CLI startup context lean, this cluster's spokes are **not** separately registered as skills — only this orchestrator and its `*-core` are enumerated. When you route to a spoke named above, **load it on demand** by reading its file:5859`~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md` (or `skills/<spoke-name>/SKILL.md` inside the skill-clusters repo).
Sheshiyer