kinwisenz-devops/flutter-developer

Applies the official Effective Dart rules to written Dart code: identifier naming, import ordering, formatting, doc comments, null safety usage, collections, async, error handling, types, parameters, equality and public API design. Use when writing, reviewing or cleaning up Dart code, naming things, or designing a library API. Do not use for app structure or state management (flutter-architecture) or for performance work.

Applies the Flutter team's app architecture recommendations: UI and data layers, MVVM, repositories, unidirectional data flow, immutable models, dependency injection, navigation, naming and testing with fakes. Use when structuring a Flutter app or feature, deciding where logic belongs, reviewing widgets that hold logic, or planning tests per layer. Do not use for Dart naming and style (dart-code-standards) or for profiling and rebuild tuning.

Applies a design system in Flutter through the theme layer: ThemeData, ColorScheme, TextTheme, ThemeExtension design tokens, light and dark themes, shared themed widgets, accessibility checks and dashboard screens (stat strips, cards, adaptive layout). Use when theming an app, mapping a design team's tokens to Flutter, removing hard-coded colours or sizes, adding dark mode, checking contrast, tap targets and text scaling, or building a dashboard or data-heavy screen. Do not use for app structure (flutter-architecture) or for API integration.

Router and shared guardrails for Dart and Flutter development work, including Django API integration and design systems: picks the right specialist skill and enforces verify-before-claiming, smallest-change and honest close-out rules. Use when a task touches Dart or Flutter code, when starting any Flutter change, or when it is unclear which skill applies. Do not use for backend work, or for performance profiling and optimisation.

Guides the Flutter side of integrating with a Django REST Framework backend: service and repository layering, OpenAPI contract and client generation, JSON model mapping, JWT authentication and token storage, error and validation mapping, pagination, environments and web CORS. Use when a Flutter app calls a Django API, when adding or changing an endpoint client, auth flow, error handling or list loading, or when the app and API disagree. Do not use for writing the Django server code or for UI theming.

Plans and performs Flutter and Dart SDK upgrades and breaking-change migrations: deprecated API removals, Android Gradle Plugin and Kotlin build changes, and other changes listed on the Flutter breaking-changes page. Use when upgrading the Flutter or Dart version, when a build fails after an SDK or Android Gradle Plugin upgrade, or when fixing a deprecation warning tied to a specific Flutter version. Do not use for app-level architecture decisions (flutter-architecture) or for routine feature work with no version or build change involved.

Runs a research-only investigation before a task is planned: reads the codebase and authoritative sources, records verified findings in one research note, weighs alternatives and converges on a single recommended approach without editing code. Use when asked to research, investigate, analyse how something works, compare approaches or prepare a plan for a Flutter or Dart task. Do not use to implement changes or to score technical debt (flutter-tech-debt-plan).

Produces a scored technical debt remediation plan for Flutter and Dart code, tests and documentation, with a summary table and a detailed plan per item, without changing code. Use when asked to audit tech debt, find code smells, assess missing tests or outdated docs, or plan a clean-up. Do not use for fixing the debt (flutter-developer) or for open-ended investigation (flutter-task-research).

Applies core Flutter widget practice when writing or fixing widget code: stateless versus stateful choice, const widgets, the State lifecycle and disposing controllers, keys in reorderable lists, layout constraint errors, updating state without mutating shared lists, forms and validation, basic screen navigation, implicit animations, adaptive layout and reading error messages. Use when building or reviewing a widget or screen, fixing a layout or "unbounded height" error, a state that does not update or resets, a form, or when a newcomer needs the basics explained. Do not use for app layers and state management choice (flutter-architecture), theming (flutter-design-system), API calls (flutter-django-integration) or profiling.

Writes and reviews GNU Make Makefiles that wrap repeatable project commands such as code generation, analysis, tests and builds, covering structure, variables, phony targets, recipes, includes and portability. Use when adding or fixing a Makefile, a make target, or a task runner for a Flutter or Dart project. Do not use for Dart code rules (dart-code-standards) or for CI workflow files.