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.
- Existing-interface diagnosis: use
- Before implementation, record one explicit visual direction: type character, density, palette behavior, geometry, imagery, and motion character. Read
references/visual-direction.mdandreferences/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.mdand 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.