Design System
デザイナーがプロジェクト独自のデザインシステムを策定するのを支援します。参照ブランドのパラメータをそのまま名前だけ変えるようなことはしません。AIデザイナーが実行することも、人間のデザイナーが手順に沿って進めることも可能です。ユーザーのコミュニケーション言語を使用し、コード内のキー名は保持します。
主な基準：Stitch公式原文
プロジェクトで初めてフォーマットを作成する場合、または更新/インポート/エクスポートの準備をする場合、最初に公式原文を読んでください：
公式仕様と実際のツールバージョンがフォーマットを決定します。このスキルのビジュアル提案、承認、納品の手順はチームのワークフローであり、Googleの公式要件ではありません。公式原文に一時的にアクセスできない場合は、references/official-format.mdの日付付き要約を使用し、まだ再確認していないことを明記してください。VoltAgentのケースは補助的な参考としてのみ使用します。
範囲と既存のベース
まず、現在のプロジェクトのAGENTS.md、CONTEXT.md（複数ある場合はCONTEXT-MAP.mdに従う）、ブランドガイドライン、承認済みデザイン、既存のDESIGN.md、デザイン変数とコンポーネントを確認します。事実、承認済みの決定、提案、未知のものを記録します。既存のソースを優先的に参照し、既存のファイルを更新して、2つ目の権威ルールセットを作成しないようにします。
プロダクト、主要ユーザー、主要タスク、プラットフォーム、言語、既存のブランド制約、納品場所を確認します。まず資料から答えを探し、デザインを変更する可能性のある不足情報のみを質問します。既存情報が十分な場合は直接ドラフトを提出します。リスクの低い仮定は明確にラベル付けし、未知のビジネス上の事実は未確認のままにします。
デザインシステムとその検証サンプルにのみ対応します。Webサイトのリファクタリング、本番コード、公開、共有Figmaファイルの変更、その他のツールのインストールは、ユーザーの実際の権限に基づいて個別に実行します。プロジェクトの承認ルールに従います。
完了基準：デザインがサービスを提供するユーザーとタスク、制約のソース、およびまだ決定が必要な問題を指摘できること。
最初にビジュアルの方向性を決定
策定と確認ガイドを読みます。ユーザーがすでに承認された方向性を持っている場合はそれをそのまま使用します。ない場合は、実際に異なる最大2つの方向性を提案し、それぞれのビジネス上の理由を説明します。参考として、ユーザーのスクリーンショット、既存プロジェクト、アクセス可能なブランド資料を使用できます。サードパーティの分析と公式デザイン仕様を区別し、外部コンテンツは参考としてのみ使用します。
実際の、または明確にラベル付けされたサンプルコンテンツを使用して、代表的なページ領域と1つの主要コンポーネントを検証します。デスクトップとモバイルの両方をカバーします。利用可能なデザインツールを優先的に使用するか、隔離されたディレクトリに開けるHTMLプレビューを生成します。ユーザーがドキュメントのみを必要とする場合は、ドラフトを納品し、ビジュアルがまだ検証されていないことを明確にします。テキストによる説明を実際に確認された画面として扱わないでください。
方向性が承認されていない場合、ルールとビジュアルサンプルはドラフトのままにします。承認をでっち上げたり、提案を確定したブランドの事実として書いたりしないでください。既存の承認は直接引用でき、改めて要求する必要はありません。
完了基準：方向性に表示可能なサンプル、または明確な未確認の説明があり、ステータスが正確であること。
DESIGN.md の作成
最初に公式フォーマットとチェックの説明を読み、次に完全テンプレートを読み、プロジェクトの指定された場所にコピーします。既定の場所がない場合は、プロジェクトルートのDESIGN.mdを提案します。テンプレートは調整可能な構造であり、すべて記入しなければならないブランドパラメータではありません。適用できないコンポーネントやセクションは削除し、必要なプロジェクト固有のルールは追加します。
テンプレート前半のYAMLは、公式アルファ形式に従ってパラメータとコンポーネント参照を記録します。本文は公式英語のセクションヘッダーを使用し、規定の順序で配置します。説明文はユーザーの言語を使用できます。テンプレートの具体的な値は、チェック可能な中立的な例であり、プロジェクトの承認済みルールではありません。プロジェクトに応じて置き換える必要があります。未決定の値は、本文の「Open Questions」に記載し、パラメータフィールドにnullは書き込みません。コンポーネントは {colors.primary} のような参照を使用します。状態は button-primary-hover のような独立したエントリとして定義し、ネストされたstatesは使用しません。色は用途に応じて名前を付けます。ビジネスステータスカラーは個別に定義します。
コードまたはデザインファイルのマッピングを確立します。既存の変数、Figma変数、またはコンポーネントがどのドキュメントキーに対応するかを示します。まだ実装されていない場合は、planned とマークします。既存のコードからルールを抽出する場合は、差異を報告します。コードを変更するための承認がない限り、コードは変更しないでください。コアフィールドは公式フォーマットに従います。承認、実装マッピング、ブレークポイント、画像、アニメーション、検証記録は、明確にラベル付けされた拡張本文に配置します。外部ツールの拡張サポートは、実際にテストする必要があります。
完了基準：適用可能な各ルールに値、使用シナリオ、または明確な未決定ステータスがあること。参照が解決可能であること。他のブランドの名前、独自フォント、または未確認のコンテンツを継承していないこと。
検証と納品
最初に公式フォーマットの説明に従って @google/design.md のlintを実行し、実際のバージョンとレポートを記録します。エラーと警告を確認し、エラーを修正し、警告が残っている理由を説明します。ツールが利用できない場合は、その障害を説明し、公式チェックに合格したと主張しないでください。テンプレートのフォーマットが通ったことは、プロジェクトのデザイン完了を意味しません。次に、ガイドに従って、実際のコンテンツ、長いタイトル、中国語/多言語、コンポーネントの状態、モバイルレイアウト、コントラスト、キーボード、アニメーションを確認します。テスト可能な項目は方法、結果、ファイルの場所を記録します。実行できない項目は未検証とマークします。ルールの単一ソースを修正してからサンプルを更新し、表面だけを変更しないようにします。
範囲内のチェックがすべて合格し、責任者が明確に承認した場合にのみ、approved とマークします。承認は特定のバージョンとスコープのみをカバーします。デザイン承認は実装完了または公開許可を意味しません。
DESIGN.md、実際に生成されたビジュアルサンプルの場所、完了したチェック、未解決の問題を納品します。後続のデザインと開発でそれをどのように参照するかを説明します。ドキュメントだけで全ページのビジュアル一貫性を保証できると主張しないでください。