design-system-generator

デザインシステムジェネレーター

製品で実際に使われている技術スタックとビジュアル言語に基づき、簡潔なデザインシステムを作成します。今後の UI 作業で一貫性を保つための決定事項を文書化します。

委任

デフォルトではメインの会話で実行します。委任によって使用量が増えることがあります。サブエージェントを使用する前に、予定するエージェントの数と作業範囲について明示的な承認を得てください。承認された範囲内ではその承認を再利用し、承認済みの数や範囲を超える場合は、事前に再度確認してください。

提案の前に調査する

既存のデザイン文書、ブランド資料、代表的な画面、共有コンポーネント、テーマ設定、トークン、ビルドツールを確認します。これらの情報源から、フレームワーク、CSS の手法、テーマ、ブラウザーのサポート対象、エクスポート形式を推定します。文書に重大な影響を及ぼす、未解決の製品上の選択肢についてのみ質問してください。

確立された一貫性のあるシステムがある場合は、それを維持します。新しい製品では、ユーザーの制約に適した方針を 1 つ推奨します。比較が有用な場合、または依頼された場合にのみ、代替案を比較します。このスキルの例に合わせるためだけに、コンポーネントライブラリを追加したり、ビルドツールを移行したりしないでください。

プロジェクトの規約を文書化する

テンプレートをトピックの一覧として使用します。該当しないセクションは省略し、例はプロジェクトで確認済みの決定事項に置き換えます。関連する以下の項目を網羅してください。

• サーフェス、テーマ、デバイス、言語や RTL の制約
• トークンの管理主体、タイポグラフィ、色、間隔、レイアウト、モーション
• 共有コンポーネントと、それぞれが実際にサポートするインタラクション状態
• トークン、コンポーネント、ユーティリティ、ローカルな例外に関する拡張ルール
• キーボード操作、視認できるフォーカス、コントラスト目標、セマンティックマークアップ、モーションの低減
• 同等の状態とビューポートでのビジュアル検証
• デザインシステムが管理する場合の、アセット読み込みとキャッシュ無効化の責任範囲

パイプラインの詳細については、既存のビルドやデプロイのガイダンスにリンクしてください。ハッシュ付きファイル名やマニフェストはキャッシュ戦略の一例であり、新しいビルドシステムとして必須ではありません。製品で使用していないフレームワークやテーマのサポートを文書化しないでください。

記述は実行可能で、プロジェクト固有のものにします。この文書は製品チーム向けです。プロンプトの作成方法や一般的なフレームワークのチュートリアルは含めないでください。

成果物

既存のデザインシステムの管理元を更新するか、リポジトリの慣例に沿った場所に DESIGN_SYSTEM.md を作成します。合意した実装に必要な場合、または依頼された場合に限り、CSS または JSON のトークンをエクスポートします。これらの形式を使う場合にのみ examples/tokens.css と examples/design-tokens.json を読みます。examples/manifest.example.json が関係するのは、マニフェストを使ったパイプラインの場合に限ります。

見つけやすさを高めるために指示ファイルへのリンクが必要な場合は、examples/AGENTS.patch.md の最小限のパターンを使用し、既存の AGENTS.md／CLAUDE.md の管理元やシンボリックリンクを維持してください。指示ファイルを重複して追加したり、デザインルールを繰り返し記載したりしないでください。

検証

文書に記載したパス、トークン名、コンポーネント API、ビルドに関する記述を、それぞれの管理元と照合します。ビジュアル上の判断を行う場合やトークンを変更する場合は、代表的なレンダリング済みコンポーネントを確認します。ビジュアル検証を実行できなかった場合は、その旨を報告します。プレースホルダー、矛盾、情報源の重複を取り除きます。

文書とエクスポートした内容、重要な決定事項、実施した検証、未解決の選択肢を報告します。