rule-flutter-flutter-architecture-always-on

Name: rule-flutter-flutter-architecture-always-on
Availability: InStock
Author: belluga

Enforce Flutter architectural tenets for widget purity, controller ownership, and AutoRoute governance.

Updated Nov 7, 2025

Search Tags:#architecture #routing #state-management #flutter #dependency-injection #module-ownership

Ready to run

npx skills add https://github.com/belluga/delphi-ai --skill rule-flutter-flutter-architecture-always-on

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: rule-flutter-flutter-architecture-always-on
Source: https://github.com/belluga/delphi-ai/tree/main/.cline/skills/rule-flutter-flutter-architecture-always-on
Command: npx skills add https://github.com/belluga/delphi-ai --skill rule-flutter-flutter-architecture-always-on

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Flutter projects often drift from architectural tenets, leading to tangled widgets, unclear state ownership, and brittle routing. This Rule enforces clear separation of concerns and governance across the Flutter client.

Core Features & Use Cases

Enforces widget purity by ensuring controllers own all state and orchestration; widgets remain presentation-only.
enforces DI/ownership boundaries and route governance with AutoRoute and guarded navigation.
Use Case: In a new feature module, the rule ensures that a screen's state is managed by a controller and that navigation uses AutoRoute with proper guards, preventing ad-hoc Navigator usage.

Quick Start

Apply this rule to every Flutter feature to ensure architectural consistency and prevent scope creep.

Frequently Asked Questions about rule-flutter-flutter-architecture-always-on

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I enforce Flutter architecture rules to keep widgets presentation-only?▼

Enforce Flutter architecture by ensuring all state and orchestration are owned by controllers, leaving widgets purely for presentation. This separation prevents tangled widgets and unclear state ownership across your client app.

How do I manage state ownership boundaries in Flutter feature modules?▼

Manage state ownership by requiring module-scoped ownership for controllers and enforcing strict dependency injection boundaries. This approach ensures each module owns its state, preventing scope creep and architectural drift.

What is the best way to govern routing and navigation in Flutter?▼

Govern Flutter routing by using AutoRoute with proper navigation guards. This prevents ad-hoc Navigator usage and enforces route governance, ensuring secure and consistent navigation across all modules.

Why does my Flutter project drift from its architectural tenets during feature development?▼

Flutter projects drift from architectural tenets due to unclear state ownership and ad-hoc navigation. Enforcing widget purity, controller ownership, and route governance across modules solves this by establishing clear separation of concerns.

Can I use ad-hoc Navigator instead of AutoRoute for Flutter module navigation?▼

You should not use ad-hoc Navigator. The architecture requires AutoRoute with proper guards to enforce route governance and DI boundaries, ensuring navigation remains consistent, guarded, and testable across modules.

Do I need dependency injection to maintain Flutter widget purity?▼

Yes, dependency injection is required to maintain widget purity. Enforcing DI boundaries ensures controllers own all state and orchestration, keeping widgets strictly presentation-only and preventing tangled dependencies.