Design, refactor, review, or implement Flutter app architecture using MVVM, layered UI/Data/optional Domain boundaries, feature-first or layer-first project structure, repositories, services, dependency injection, Result and Command patterns, offline-first or optimistic UI flows. Use when asked to add a Flutter feature, audit layer dependencies, fix cross-feature imports, migrate to feature-first, choose architecture for a Flutter project, or create scalable maintainable Flutter code organizatio
This skill acts as an architecture agent for Flutter apps, helping design, refactor, review, or implement application structure using MVVM and layered UI/Data/optional-Domain boundaries. It solves the problem of choosing and enforcing a scalable, maintainable code organization by turning concrete project facts (pubspec, lib layout, existing state-management, routing, DI, and persistence conventions) into structure decisions, dependency rules, and validation steps rather than generic advice.
The skill defines a core contract: confirm the project is Flutter/Dart, preserve existing conventions unless migration is requested, pick the smallest fitting architecture (feature-first for medium/large or team apps, layer-first for small or solo apps), add a Domain layer only for complex or reusable logic, and keep Views thin, ViewModels responsible for UI state and commands, Repositories as the single source of truth, and Services as stateless external-source wrappers. It validates with the repo's normal commands, preferring `flutter analyze` and relevant `flutter test`. A resource-routing table points to reference documents on concepts, layer responsibilities, feature-first structure, MVVM relationships, and design patterns (Command, Result, Repository, DI, offline-first, optimistic UI), plus copyable Command and Result Dart templates that are only to be used after adapting imports and state-management fit. Detailed references spell out layer responsibilities, unidirectional data flow, testing strategy per layer, and clarification rules for high-impact decisions.
Target users are Flutter developers and teams adding features, auditing layer dependencies, fixing cross-feature imports, migrating to feature-first, or choosing an architecture. Use cases span greenfield structure decisions, refactors, and architecture reviews.
It recommends feature-first for medium/large apps, team work, frequent feature changes, or clearly bounded capabilities, and layer-first for small apps, solo work, or simple CRUD flows, always choosing the smallest architecture that fits.
Only when logic merges data from multiple repositories, is exceedingly complex, or will be reused by different ViewModels. For simple flows, ViewModels may call Repositories directly rather than forcing use-cases.
Both. For implementation tasks it changes structure and code using local patterns first, adding skill templates only after checking import, SDK, and state-management fit. For review tasks it reports layer violations, cross-feature imports, and state-ownership issues.
With the repo's normal commands, preferring `flutter analyze` and relevant `flutter test` suites; if validation is unavailable it explains what could not be verified rather than inventing results.
It gives an architecture plan or review based on provided context, does not invent repository facts, and states that code validation could not be performed.
Quick Setup:
.claude/skills/Repository
madteacher/mad-agents-skills