FL
flutter-mail-project-architecture
Use when planning, scaffolding, or refactoring the overall Flutter Inbox One project structure in this repository, especially when deciding file placement, MVC boundaries, routing/theme foundations, or stage order. Do not use for isolated single-layer edits that clearly belong only to models, servic
Install
mkdir -p .claude/skills/flutter-mail-project-architecture && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/16549" && unzip -o skill.zip -d .claude/skills/flutter-mail-project-architecture && rm skill.zipInstalls to .claude/skills/flutter-mail-project-architecture
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Use when planning, scaffolding, or refactoring the overall Flutter Inbox One project structure in this repository, especially when deciding file placement, MVC boundaries, routing/theme foundations, or stage order. Do not use for isolated single-layer edits that clearly belong only to models, services, controllers, or views.326 chars✓ has a “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
About this skill
Flutter Mail Project Architecture
Read first
dev/PRD.mddev/TDD.mddev/DELIVERY_PLAN.md- Root
AGENTS.md - The closest nested
AGENTS.mdfor the directories you touch
Core architecture
- This repository follows an MVC-style Flutter structure:
lib/modelslib/serviceslib/controllerslib/viewslib/other
- Keep cross-layer responsibilities clean:
- models define data shapes
- services talk to APIs/local storage
- controllers own state and actions
- views render UI
- other contains router/theme/utils/constants
Delivery order
- Respect the staged flow in
dev/DELIVERY_PLAN.md. - Prefer this order unless the user explicitly reprioritizes:
- Foundation
- Inbox Parity
- Action & AI Completion
Structural decisions
- Preserve document-defined folder names and boundaries unless the docs are intentionally updated.
- If a request would mix multiple responsibilities into one layer, split the work before coding.
- When introducing shared logic, place it in the narrowest stable layer instead of leaking it upward into views or downward into models.
Output expectations
- When you make structural changes, mention which stage the work belongs to.
- Call out any doc conflict before silently diverging from the PRD/TDD.