| name | flutter-themis-standard |
| description | Standard guidelines for Flutter development in the Themis project. Use this skill whenever initiating UI tasks, creating widgets, or implementing Flutter features. It ensures visual, structural, and technical consistency by integrating prototypes, design guides, and existing patterns. |
Flutter Themis Development Standard
This skill defines the technical and architectural standards for Flutter development within the Themis project. Adherence to these guidelines is mandatory to ensure a cohesive identity, optimal performance, and maintainable code.
Core Workflow
- Contextual Research: Before implementation, examine existing patterns in
lib/shared/widgets/ and previously implemented screens in lib/features/.
- Focus Shift to Logic (Post-UI Baseline): The static UI baseline is already consolidated. Your primary responsibility now is to connect screens using Riverpod Providers and implement Clean Architecture's Data/Domain layers to consume the hardened Backend.
- Layout Refinements: If constructing UI, use the
flutter-building-layouts skill. Enforce the Themis UI standard:
- No Bleeding: Always respect
SafeArea. The AppBottomNavigationBar and SystemUiOverlayStyle must create a clean edge-to-edge experience without dark native bars intersecting the app.
- Clean Aesthetics: Use white backgrounds for headers (AppBars), semantic consistency, and avoid excessive
Dividers. Use margins and spacing hierarchically.
Identity and Styling
Refer to documentation/design-guide.md for the following specifications:
- Colors: Use defined tokens (Primary:
#1A237E, Gold: #DEBC74, etc.).
- Typography: Utilize the
Inter font family. Standards: H1 (24px, Bold), H2 (18px, Semi-Bold), Body (16px).
- Spacing: Maintain consistency using 4px or 8px increments. Prefer whitespace parsing over linear dividers.
Architecture and Organization
- Vertical Slicing & Layering: We strictly follow "Full Vertical Slicing" with Clean Architecture. Every functionality is an isolated sub-feature.
- Each sub-feature has its own layers:
<sub-feature>/data/: repositories, models, data_sources.<sub-feature>/domain/: repositories, entities, usecases.<sub-feature>/presentation/: screens, widgets, providers.
- Widget Placement:
- Global/Brand-Identity Widgets (NavBars, Base AppBars, Tokens):
lib/shared/widgets/.
- Feature-specific Widgets:
lib/features/<role>/<sub-feature>/presentation/widgets/.
- State Management: Mandatory use of
Riverpod for state logic. Do not pass business state purely via widget constructors.
- Naming Conventions: Use
snake_case for filenames and PascalCase for classes.
Reference Documentation
Consult the following documents for absolute requirements:
documentation/design-guide.md: Visual identity and navigation logic.documentation/architecture.md: Section 3 acts as the ultimate truth for the Frontend structure, Data models, and API boundaries.documentation/documents/*: Technical specifications and roadmaps.
Quality Standards
- Accessibility: Ensure touch targets are at least
48x48dp. Maintain WCAG AA contrast ratios.
- Performance: Minimize unnecessary rebuilds. Use
const constructors wherever possible.
- Validation: Code must pass
flutter analyze without significant warnings.
- Visual Feedback: Implement
LoadingSkeleton from shared/widgets/ for all loading states.
Note: This skill evolves with the project. When a better pattern is established in the codebase, prioritize the implementation in the code over the prototype or documentation.
