Flutter architecture

Skill almasumdev/awesome-flutter-agent-skills/.github/skills/architecture/flutter-architecture

Curated agent skills, conventions, and workflows for building Flutter apps with AI coding agents.

Install

npx -y skills add almasumdev/awesome-flutter-agent-skills --skill flutter-architecture

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Expert guidance on setting up and maintaining a modern Flutter application architecture using Clean Architecture, feature modularization, and dependency injection. Use this when asked about project structure, package layout, or DI.

SKILL.md

3.1 KB, as published. Nobody here has run it

Flutter Modern Architecture & Modularization

Instructions

When designing or refactoring a Flutter application, follow Clean Architecture principles. Dependencies must flow inwards toward pure Dart domain code.

1. High-Level Layers

Presentation Layer:
- Responsibility: Rendering widgets and handling user interactions.
- Components: Widgets, ConsumerWidgets, StateNotifier/Notifiers, Bloc/Cubits, view-models.
- Dependencies: Depends on the Domain Layer (UseCases or repository interfaces).
Domain Layer (Pure Dart):
- Responsibility: Business rules and domain entities.
- Components: UseCases (e.g., GetLatestArticles), Entities (immutable value classes, prefer freezed), Repository interfaces.
- Rule: Must NOT import package:flutter/*. Keep it under lib/domain/ or a separate domain package.
Data Layer:
- Responsibility: Fetching, caching, and persisting data.
- Components: Repository implementations, DataSources (Dio clients, Drift/Isar DAOs), DTOs + mappers to domain entities.

2. Dependency Injection

Prefer Riverpod (Provider, NotifierProvider, FutureProvider) as the DI mechanism — it is compile-time-safe, testable, and avoids service locators.

final dioProvider = Provider<Dio>((ref) => Dio(BaseOptions(baseUrl: Env.api)));
final articleRepoProvider = Provider<ArticleRepository>((ref) =>
    ArticleRepositoryImpl(ref.watch(dioProvider), ref.watch(articleDaoProvider)));

If the team uses get_it + injectable, centralize registration in lib/di/injection.dart and call configureDependencies() in main() before runApp.

3. Modularization Strategy

For production apps, split by layer and feature using the melos-style multi-package layout or a clean lib/ folder structure:

lib/
├── core/           # Theme, constants, error types, networking client
├── data/           # Repository implementations, DTOs, datasources
├── domain/         # Entities, repository interfaces, usecases (pure Dart)
├── features/
│   └── articles/
│       ├── data/          # feature-specific datasource/repo impl
│       ├── domain/        # feature entities + usecases
│       └── presentation/  # widgets, providers, screens
└── main.dart

For large apps, promote core/, domain/, and each feature/ to its own package in packages/ and orchestrate with melos.

4. Checklist for implementation

Domain layer has zero Flutter imports (verify with flutter analyze + custom lint avoid_flutter_imports).
Repositories expose domain entities only — never DTOs.
Providers/BLoCs surface immutable state objects (use freezed); see flutter-state-management skill.
Features are self-contained and do not import siblings directly.