# Architecture Feature First

Use when creating a feature, designing folder structure, adding...

- Repository: https://github.com/evanca/flutter-ai-rules (668 stars)
- Category: Design
- License: MIT
- Last updated: 2026-10-30
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add evanca/flutter-ai-rules --skill architecture-feature-first -g -a claude-code -y`
Codex: `npx skills add evanca/flutter-ai-rules --skill architecture-feature-first -g -a codex -y`
Cursor: `npx skills add evanca/flutter-ai-rules --skill architecture-feature-first -g -a cursor -y`
Gemini CLI: `npx skills add evanca/flutter-ai-rules --skill architecture-feature-first -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add evanca/flutter-ai-rules`

## Description

Use when creating a feature, designing folder structure, adding repositories/services/view models, wiring dependency injection, or deciding which layer owns logic.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Flutter Architecture, Feature-First Skill

This skill defines how to design, structure, and implement Flutter applications using the recommended **layered architecture** with **feature-first** file organization.

It is **state management agnostic**: the business logic holder in the UI layer may be named ViewModel, Controller, Cubit, Bloc, Provider, or Notifier, depending on the chosen state management approach. The architectural rules apply equally to all of them.

## When to Use

Use this skill when:

* Designing the folder/file structure of a new Flutter app or feature.
* Creating a new View, ViewModel, Repository, or Service.
* Deciding which layer owns a piece of logic.
* Wiring dependency injection between components.
* Adding a domain (logic) layer for complex business logic.
* Refactoring an existing app from type-first to feature-first organization.

---

## 1. Layers

Separate every app into a **UI Layer** and a **Data Layer**. Add a **Logic (Domain) Layer** between them only for complex apps.

```
┌──────────────────────────────────────────────────────────────┐
│   UI Layer    │  Views + business logic holders              │
│               │  (ViewModel / Cubit / Controller / Provider) │
├──────────────────────────────────────────────────────────────┤
│  Logic Layer  │  Use Cases / Interactors  (optional)         │
├──────────────────────────────────────────────────────────────┤
│   Data Layer  │  Repositories + Services                     │
└──────────────────────────────────────────────────────────────┘
```

**Rules:**
- Only adjacent layers may communicate. The UI layer must never access a Service directly.
- The Logic layer is added **only** when business logic is too complex for the business logic holder or is reused across multiple screens.
- Data changes always happen in the Data layer (SSOT = Repository). No mutation in UI or Logic layers.
- Follow unidirectional data flow: state flows **down** (Data → UI), events flow **up** (UI → Data).

The rest: https://github.com/evanca/flutter-ai-rules/blob/HEAD/skills/architecture-feature-first/SKILL.md