| name | flutter-design |
| description | Orchestrate product-aware Flutter UI design and redesign from repository inspection through rendered verification. Use for new Flutter screens, multi-screen flows, major visual redesigns, design-led implementation, or ambiguous Flutter UI requests that require routing across audit, design-system, implementation, motion, accessibility, and visual-QA workflows. |
Flutter Design
Design with evidence. Do not jump from a vague request to widget code.
Workflow
- Inspect
pubspec.yaml, Flutter/Dart versions, app structure, theme, routing, state management, reusable widgets, tests, and current git state.
- Identify the product, primary user, critical action, platform mix, content hierarchy, constraints, and measurable success condition.
- Classify the work and invoke the smallest useful specialist set:
- Existing-interface diagnosis: use
$flutter-audit.
- Tokens, themes, or component contracts: use
$flutter-design-system.
- Approved UI implementation: use
$flutter-implementation.
- Transition or interaction motion: use
$flutter-motion.
- Accessibility, text scaling, keyboard, or RTL: use
$flutter-accessibility.
- Rendered review or golden tests: use
$flutter-visual-qa.
- Before implementation, record one explicit visual direction: type character, density, palette behavior, geometry, imagery, and motion character. Read
references/visual-direction.md and references/anti-slop.md.
- Enumerate data and interaction states: initial, loading, empty, populated, partial, error, offline, disabled, destructive confirmation, and success as applicable.
For multi-domain dashboards or connected tools, read
references/connected-product-workflows.md and define the connective model before arranging regions.
- Define acceptance criteria for compact and expanded layouts, themes, text scaling, and critical interactions.
- Implement only after direction and states are explicit.
- Require static checks, rendered evidence, accessibility review, and one refinement pass before completion.
Gates
- Ask one focused question when missing product context would materially change the design.
- Offer two or three visual approaches when direction is genuinely open; recommend one with product reasoning.
- Preserve existing business behavior unless the user authorizes behavior changes.
- Treat screenshots as evidence. Never claim visual parity or polish without inspecting rendered output.
- Report environmental limits explicitly when rendering or tests are unavailable.
Output Contract
Lead with the implemented or recommended outcome. State the chosen direction, important interaction decisions, verified viewport/theme combinations, tests run, and unresolved limitations. Avoid narrating routine file operations.
