flutter-design

Flutter デザイン

根拠に基づいてデザインします。曖昧な依頼から、いきなりウィジェットのコードに進んではいけません。

ワークフロー

1. pubspec.yaml、Flutter／Dart のバージョン、アプリの構成、テーマ、ルーティング、状態管理、再利用可能なウィジェット、テスト、現在の Git の状態を確認します。
2. プロダクト、主なユーザー、重要なアクション、対象プラットフォーム、コンテンツの階層、制約、測定可能な成功条件を特定します。
3. 作業を分類し、必要最小限の専門家セットを呼び出します。
   • 既存インターフェースの診断：$flutter-audit を使用します。
   • トークン、テーマ、コンポーネントの契約：$flutter-design-system を使用します。
   • 承認済みの UI 実装：$flutter-implementation を使用します。
   • トランジションやインタラクションのモーション：$flutter-motion を使用します。
   • アクセシビリティ、テキストの拡大、キーボード、RTL：$flutter-accessibility を使用します。
   • レンダリング結果のレビューやゴールデンテスト：$flutter-visual-qa を使用します。
4. 実装前に、書体の特徴、密度、パレットの使い方、形状、画像、モーションの特徴を含む、明確なビジュアルの方向性を1つ記録します。references/visual-direction.md と references/anti-slop.md を読みます。
5. データとインタラクションの状態を列挙します。該当するものとして、初期、読み込み中、空、データあり、一部表示、エラー、オフライン、無効、破壊的操作の確認、成功があります。 複数の領域にまたがるダッシュボードや連携ツールでは、references/connected-product-workflows.md を読み、領域を配置する前に連携モデルを定義します。
6. コンパクトおよび拡張レイアウト、テーマ、テキストの拡大、重要なインタラクションについて、受け入れ基準を定義します。
7. 方向性と状態を明確にしてから実装します。
8. 完了前に、静的チェック、レンダリング結果の確認、アクセシビリティレビュー、1回の改善を必須とします。

ゲート

• 不足しているプロダクト情報によってデザインが大きく変わる場合は、焦点を絞った質問を1つします。
• 方向性が本当に決まっていない場合は、ビジュアルのアプローチを2〜3案提示し、プロダクト上の理由とともに1案を推奨します。
• ユーザーが動作の変更を許可しない限り、既存のビジネス動作を維持します。
• スクリーンショットは根拠として扱います。レンダリング結果を確認せずに、ビジュアルの同等性や完成度を主張してはいけません。
• レンダリングやテストが利用できない場合は、環境上の制約を明示します。

出力の契約

最初に、実装した結果または推奨する結果を示します。選択した方向性、重要なインタラクションの決定事項、検証したビューポートとテーマの組み合わせ、実行したテスト、未解決の制約を記載します。定型的なファイル操作の説明は避けます。