About flutter-architecture
flutter-architecture is an agent skill for making architecture choices in Flutter applications. It prioritizes clear responsibilities, testable state, and replaceable dependencies while advising teams to preserve coherent existing patterns and migrate incrementally.
Key features
- 01Keep data access outside views
- 02Separate presentation, repositories, and services
- 03Use domain logic when complexity warrants it
- 04Organize code around user-facing features
- 05Verify dependency direction and testability
Use cases
- 01Choose an architecture for a new Flutter app
- 02Assess boundaries in an existing feature
- 03Plan an incremental architecture migration
- 04Check modules for dependency leaks
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/flutter-architecturein Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
evals/cases.jsonreferences/feature-boundaries-and-dependency-rules.mdgreenfield-and-evolution.mdDetails
From the project READMEFlutter Architecture
Choose the least complex architecture that keeps responsibilities clear, state testable, and dependencies replaceable.
Preserve before migrating
Inspect the existing feature structure, state mechanism, dependency injection, data sources, tests, and team conventions. Extend a coherent architecture even when it differs from a preferred example. Propose migration only for a concrete problem and make it incremental.
Baseline boundaries
- Views render state and forward user intent; keep data access and business rules outside widgets.
- Presentation logic owns UI state and commands.
- Repositories are the source of truth for domain data and coordinate services or caches.
- Services wrap external systems such as HTTP, storage, and platform plugins.
- Add use cases/domain services only when logic is reused, complex, or otherwise clutters presentation state.
- Point dependencies inward through explicit interfaces where replacement or testing justifies them.
The Flutter team's MVVM guidance is a useful default for a new scalable application, not a mandate to replace Riverpod, Bloc, Redux, or an established feature-first design.
Organization
Prefer user-facing feature boundaries. Place genuinely shared infrastructure in a small core area. Avoid global folders that accumulate unrelated models, widgets, and helpers.
Load greenfield and evolution for new-project choices or incremental migrations. Load feature boundaries and dependency rules when modules leak across features or ownership is unclear.
Verification
Demonstrate the dependency path for one feature, test presentation logic without rendering widgets where practical, and confirm no circular or UI-to-infrastructure shortcuts were introduced.