What this prompt does
This prompt scaffolds a Flutter application for [app_purpose] using clean architecture. It lays out a feature-first folder structure for your [features], state management with [state_management], the repository pattern over [data_sources], dependency injection via [di_package], navigation with [router_package], Either-based error handling (dartz), local storage with [local_storage], a Dio API client with interceptors, retry, and token refresh, a theme system with [theme_count] themes, and unit plus widget tests. It also asks for an app-initialization flow, environment configuration for dev/staging/prod, and CI/CD with [ci_platform].
The structure works because clean architecture separates domain, data, and presentation so adding a feature stays additive instead of forcing a rewrite. A feature-first layout keeps each capability in its own slice, the repository pattern isolates [data_sources] behind interfaces, and [di_package] wires it together so layers stay swappable and testable. Either-based error handling means failures flow as values, so the app degrades gracefully rather than crashing on an unhandled exception.
When to use it
- You're starting a new Flutter app and want a maintainable structure before features pile on.
- You expect the app to grow and need domain, data, and presentation cleanly separated.
- You want a tested Dio API client with token refresh and retry from day one.
- You need environment configuration for dev, staging, and production baked in.
- You're standardizing how your team structures Flutter projects.
- You want light and dark theming and CI/CD set up alongside the architecture.
Example output
Expect a project skeleton: a feature-first directory tree for your [features], repository and data-source interfaces, DI registration with [di_package], route definitions in [router_package], a Dio client with interceptors, Either-returning use cases, and example unit and widget tests. The environment configuration and a [ci_platform] pipeline round it out so the app builds and tests from a clean checkout.
Pro tips
- Name your real
[features]so the generated folders match your app; generic feature names leave you renaming everything afterward. - Pick
[state_management]your team knows — flutter_bloc and Riverpod both fit clean architecture, but consistency matters more than the choice. - Be explicit about
[data_sources](REST plus an SQLite cache, for example) so the repository layer models online and offline paths correctly. - Keep
[di_package]as get_it plus injectable if you want code-generated registration; it scales better than wiring dependencies by hand. - Set
[local_storage]per data type — lightweight key-value for settings, a relational store for structured data — rather than forcing one tool to do both. - Treat the generated tests as a starting harness and expand coverage on the domain layer first, since that's where business rules live.
