Agent-skills-standard flutter-feature-based-clean-architecture

Organize Flutter apps with modular feature-based clean architecture. Use when creating or modifying any file under lib/features/ including domain entities, repositories, data sources, or screens. (triggers: lib/features/**, feature, domain, infrastructure, application, presentation)

install

source · Clone the upstream repo

git clone https://github.com/HoangNguyen0403/agent-skills-standard

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/HoangNguyen0403/agent-skills-standard "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/flutter/flutter-feature-based-clean-architecture" ~/.claude/skills/hoangnguyen0403-agent-skills-standard-flutter-feature-based-clean-architecture && rm -rf "$T"

manifest: skills/flutter/flutter-feature-based-clean-architecture/SKILL.md

source content

Feature-Based Clean Architecture

Priority: P0 (CRITICAL)

Structure

Every feature lives in

lib/features/

with 3-layer separation (domain/data/presentation):

```
domain/
```
— Entities, failures, and Repository interfaces.
```
data/
```
— DTOs, DataSource, and Repository implementations.
```
presentation/
```
— BLoC/Cubit, pages, and widgets.

See references/folder-structure.md for complete directory blueprint.

Implementation Workflow

Create feature directory — Add new folder under
```
lib/features/
```
(e.g.,
```
lib/features/promotions/
```
).
Define domain layer — Add entities, failures, and repository interfaces with zero external dependencies.
Implement data layer — Add DTOs, data sources, and repository implementations that depend only on Domain.
Build presentation layer — Add BLoC/Cubit, pages, and widgets that depend only on Domain.
Enforce dependency rule —
```
Presentation -> Domain <- Data
```
. Domain must zero external dependencies.
Share cross-cutting logic — Move reusable utilities to
```
lib/shared/
```
or
```
lib/core/
```
.

Feature Directory Example

See implementation examples for full directory tree and cross-feature import patterns.

Reference & Examples

For feature folder blueprints and cross-layer dependency templates: See references/REFERENCE.md.

Anti-Patterns

No Cross-Feature Data Imports: Only import Domain types across features
No UI/Data in Domain Layer: Never put UI or Data classes inside
```
domain/
```
No Nested Features: Keep
```
lib/features/
```
flat with no sub-feature directories
No Direct Repository Calls: Use specific BLoCs or use-cases instead of calling other features' repositories directly from UI