ux-brief

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

ガイド付きのヒアリングを通じて、包括的でジュニア開発者にもわかりやすいデザインシステムのドキュメントを作成します。

デザイン対象

<design_target> $ARGUMENTS </design_target>

空の場合は、次のように尋ねます：「何をデザインしたいですか？コンポーネント、ページ、機能について説明してください。」

フェーズ 0：インタビューの選択（任意）

要件が不明確な複雑な機能では、まず詳しいインタビューを行うことを提案してください。

AskUserQuestion: "This design could benefit from a requirements interview to clarify goals and constraints. Would you like to explore it in depth first?"
Options:
- "Yes, interview me first" → Skill(skill: "majestic-tools:workflows:interview", args: "[design target]"), then use refined output
- "No, proceed to design discovery" → Continue to Phase 1

インタビューを提案する場合：

• デザイン対象が曖昧（例：「ダッシュボード」、「管理パネル」）
• 複数のユーザータイプやステークホルダーが関わる
• ビジネス目標が明確に示されていない
• ユーザーが何を求めているか迷っている様子がある

インタビューの提案を省略する場合：

• 対象範囲が明確な特定のコンポーネント（例：「ログインフォーム」、「設定ページ」）
• 既存の仕様書やモックアップがある
• 既存デザインの反復的な改善

フェーズ 1：コンテキストの収集

質問する前に、プロジェクトを把握してください。

1. 既存のデザイントークンを確認する（tailwind.config.js、CSS 変数）
2. 既存の UI コンポーネントを調べ、パターンを把握する
3. 技術スタックを特定する（React、Vue、Rails/Hotwire、vanilla）
4. スタイルガイドやブランド資料を確認する

フェーズ 2：要件の確認

質問は一度に1つずつ尋ねてください。選択肢を限定できる場合は、多肢選択を優先してください。

質問の項目

1. 目的と目標 - この UI で何を実現しようとしていますか？
2. ターゲットユーザー - このインターフェースを使うのは誰ですか？
3. 美的方向性 - 1つ選択してください：ブルータリスト、ミニマリスト、マキシマリスト、ラグジュアリー、遊び心のあるデザイン、レトロフューチャー
4. タイポグラフィ - 見出し用と本文用のフォントの希望
5. カラーパレット - ブランドのメインカラー、ライト／ダークテーマ、アクセントの方針
6. モーションとインタラクション - アニメーションの強さ（なし、控えめ、ドラマチック）
7. インスピレーションと参考例 - 気に入っているサイト（Stripe、Linear、Vercel など）
8. 技術的な制約 - ブラウザーのサポート、パフォーマンス、アクセシビリティ（WCAG レベル）
9. フレームワーク（必須） - tech_stack に基づき、次を提案します：
   • rails → DaisyUI + Tailwind
   • react → Tailwind または styled-components
   • デフォルト → Plain Tailwind

ビジュアル表現に関する質問（包括的なデザインシステムが必要な場合）

10. 写真のスタイル - 「写真でどのような雰囲気を伝えたいですか？」

    • 選択肢：本物らしい／自然な表情、エディトリアル／演出された写真、抽象的／芸術的、製品重視、人物重視

11. イラストのスタイル - 「イラストは必要ですか？必要な場合、どのようなスタイルがよいですか？」

    • 選択肢：不要、幾何学的／すっきりした表現、有機的／手描き風、アイソメトリック／3D、フラット／ミニマル

12. アイコン - 「ブランドに合うアイコンのスタイルはどれですか？」

    • 選択肢：アウトライン（Heroicons）、塗りつぶし（ソリッド）、デュオトーン（Phosphor）、カスタム／ブランド独自

質問のガイドライン

• 1ターンにつき質問は1つ
• 多肢選択を優先
• コンテキストから明らかな質問は省略
• 2～3問ごとに要約
• 参考例を調査 - ユーザーがサイトを挙げた場合は、そのサイトを取得する

フェーズ 3：参考例の調査

ユーザーが参考サイトを挙げた場合：

1. WebFetch を使ってサイトを取得する
2. タイポグラフィ、カラーパレット、レイアウトパターン、アニメーション、特徴的な細部を特定する
3. 共感できる点を確認するため、調査結果を提示する

よく挙げられる参考例

• Stripe：すっきりとしたグラデーション、奥行き、高級感、優れたドキュメント
• Linear：ダークテーマ、ミニマル、集中しやすい、開発者向け
• Vercel：タイポグラフィを前面に出した、自信を感じさせる余白
• Notion：親しみやすく、とっつきやすい、イラストを活かした表現
• Raycast：ダーク、実用性重視、キーボード操作を優先

フェーズ 4：デザインシステムの生成

デザインシステムのテンプレートを直接読み込みます。

Read(file_path="references/design-system-template.md")

次に、ユーザー固有の選択に合わせてカスタマイズします。

• すべての[placeholder]の値を、実際のデザイン上の決定事項に置き換えます
• カラーパレットに基づいてカラーの16進数値を入力します
• タイポグラフィの選択を設定します
• コンポーネントの仕様をカスタマイズします
• プロジェクト固有の推奨事項と禁止事項を追加します

完成したデザインシステムをdocs/design/design-system.mdに保存します。

生成時に適用するデザイン原則：

• ジュニア開発者がすぐ使える：追加の質問が不要なほど、ドキュメントを完全な内容にします
• コピー＆ペーストですぐ使える：クラス、値、設定をそのまま使用できるようにします
• 方向性を明確に定める：「あれもこれも」といった曖昧なデザインは避けます
• AIっぽい凡庸なデザインを避ける：Interフォント、紫色のグラデーション、ありがちなレイアウトは使いません

フェーズ 5：保存と設定

ステップ 1：出力先の確認

.agents.ymlでdesign_system_pathを確認します。設定されていない場合は、docs/design/design-system.mdをデフォルトとして使用します。

ステップ 2：自動プレビューの確認

AUTO_PREVIEW = config_read("auto_preview", "false")

AUTO_PREVIEWが"true"の場合：open <design-system-path>を実行します。

ステップ 3：選択肢の提示

AskUserQuestionを使用します。

自動プレビューされていない場合：

• エディターでプレビュー
• 構築を開始（推奨）- skill frontend-designを呼び出す
• セクションを調整
• さらに調査

自動プレビューされた場合：

• 構築を開始（推奨）
• セクションを調整
• さらに調査

ワークフローとの連携

デザインシステムの完成後：

1. Skill("blueprint") - UI機能を自動で検出し、デザインシステムを参照します
2. Skill("build-task") - デザインシステムをコンテキストとして読み込みます
3. visual-validator - 仕様に照らして実装を検証します

主な原則

• 方向性を明確に定める - 曖昧なデザインは避けます
• AIっぽい凡庸なデザインを避ける - Interフォント、紫色のグラデーションは使いません
• 参考サイトを調査する - ユーザーが挙げたサイトを実際に確認します
• 明確な意見を持つ - ありがちな選択には異議を唱えます
• ジュニア開発者がすぐ使える - 追加の質問が不要なほど、完全なドキュメントを作成します
• コピー＆ペーストですぐ使える - クラスや設定をそのまま使用できるようにします