design-flow

このスキルでは、各スキルを順番に実行し、デザイナーのワークフロー全体を進めます。各フェーズを案内するガイドとして振る舞ってください。急がないでください。次のフェーズに進む前に、各フェーズを完了し、確認を得てください。

プロンプトの例

• 「デザインフロー全体を実行して」
• 「新しいプロジェクトの全プロセスを案内して」
• 「ゼロから始めて、すべての手順を案内して」
• 「ダッシュボードアプリのデザインフロー」

手順

1. Grill Me          → Clarify thinking
2. Design Brief      → Document intent
3. Info Architecture  → Define structure
4. Design Tokens     → Establish visual system
5. Brief to Tasks    → Plan the build
6. Frontend Design   → Build it
—
7. Design Review     → Run separately when ready

ルール

1. 開始時に、全体の手順（フェーズ1〜6。レビューは別途実施可能）をデザイナーに説明し、省略したいフェーズがあるか尋ねてください。よくある省略パターン：

   • アイデアがすでに明確な場合 → grill-me を省略
   • ページ全体ではなく単一のコンポーネントを作る場合 → information-architecture を省略
   • トークンがある既存のプロジェクトの場合 → design-tokens を省略

2. 各フェーズの前に、これから始めるフェーズと、そのフェーズで作成されるものを伝えてください。例：「フェーズ2：デザインブリーフ。プロジェクトについてヒアリングし、DESIGN_BRIEF.md ファイルを作成します。準備はよろしいですか？」

3. 各フェーズの実行中は、対応する SKILL.md ファイルを読み、記載された指示にすべて従ってください。スキルの内容を要約したり、省略したりしないでください。適切に実行してください。

4. 各フェーズの後に、作成されたもの（ファイル名、主な決定事項、未解決の質問）を要約し、「次のフェーズに進んでもよろしいですか？」と尋ねてください。確認を待ってください。

5. フェーズ間では、前のフェーズの成果物によって次のフェーズに変更が生じるか確認してください。たとえば、ブリーフにデザインの理念が記載されている場合、トークンのフェーズでそれを使用することを伝えてください。

6. デザイナーはいつでも中断できます。「今はここまででいいです」と言われたら、手順のどこまで進んだかを要約し、再開時の次のフェーズを伝えてください。

フェーズの詳細

フェーズ1：Grill Me

grill-me スキル（grill-me/SKILL.md）を読み、その指示に従ってください。 作成物：プロジェクトについての共通理解。ファイル出力はありません。 次への移行：「重要な決定事項が整理できました。これをデザインブリーフとしてまとめてもよろしいですか？」

フェーズ2：デザインブリーフ

design-brief スキル（design-brief/SKILL.md）を読み、その指示に従ってください。 作成物：.design/<feature-slug>/DESIGN_BRIEF.md。 次への移行：「ブリーフを保存しました。次は情報アーキテクチャです。ページ構成とナビゲーションを定義します。単一のコンポーネントを作る場合は省略できます。続けますか？」

フェーズ3：情報アーキテクチャ

information-architecture スキル（information-architecture/SKILL.md）を読み、その指示に従ってください。 作成物：.design/<feature-slug>/INFORMATION_ARCHITECTURE.md。 次への移行：「情報アーキテクチャを定義しました。次はブリーフに記載された理念に基づいて、デザイントークン（色、間隔、タイポグラフィ）を生成します。続けますか？」

フェーズ4：デザイントークン

design-tokens スキル（design-tokens/SKILL.md）を読み、その指示に従ってください。 作成物：トークンファイル（スタックに応じて、CSS 変数、Tailwind 設定、またはテーマファイル）。 次への移行：「トークンを設定しました。次はブリーフをタスクリストに分解し、順番に実装できるようにします。続けますか？」

フェーズ5：ブリーフからタスクへ

brief-to-tasks スキル（brief-to-tasks/SKILL.md）を読み、その指示に従ってください。 作成物：.design/<feature-slug>/TASKS.md。 次への移行：「タスクの準備ができました。次はいよいよ構築です。リストの最初のタスクから始めます。続けますか？」

フェーズ6：フロントエンドデザイン

frontend-design スキル（frontend-design/SKILL.md）を読み、その指示に従ってください。 TASKS.md のタスクを順番に進めてください。各タスクの完了後にチェックを付け、次のタスクに進む前にデザイナーの確認を得てください。 作成物：構築されたコンポーネントとページ。 次への移行：「これで一連のフローは完了です。ブリーフ、情報アーキテクチャ、トークン、タスクはすべてプロジェクトに保存されています。デザインレビューの準備ができたら、/design-review を実行してください。ブリーフと照らし合わせて構築内容を批評します。」

フローはここで終了します。 フェーズ7は自動では実行されません。

フェーズ 7：デザインレビュー（依頼があった場合のみ）

このフェーズは自動では実行されません。次の場合にのみ実行されます。

• デザイナーがフローの途中で明示的にレビューを依頼した場合
• デザイナーが構築後に /design-review を個別に実行した場合

レビューには、確認対象となる構築済みのコードが必要です。コンポーネントやページがまだ構築されていない場合、このフェーズは実行しないでください。代わりに、デザイナーに「構築が完了したら /design-review を実行してください。出力をブリーフと照らし合わせて確認します」と伝えてください。

レビューを開始するときは、design-review スキル（design-review/SKILL.md）を読み、その指示に従ってください。レビューでは、Playwright MCP（推奨）、Cursor IDE Browser（代替）、またはブラウザツールが利用できない場合はユーザーに手動で提供してもらう方法で、実行中のアプリケーションのスクリーンショットを撮影します。

生成物：.design/<feature-slug>/DESIGN_REVIEW.md ＋ .design/<feature-slug>/screenshots/ に保存されるスクリーンショット。 移行時のメッセージ：「レビューが完了しました。スクリーンショットは .design/<feature-slug>/screenshots/ に保存されています。必ず修正が必要な項目があれば、今すぐ対応できます。」

プロジェクトファイルの構成

デザインフローの成果物はすべて .design/<feature-slug>/ 以下に保存されます。<feature-slug> は、デザイン対象の機能に由来する短い小文字のハイフン区切りの名前です。これにより、複数の機能を互いに上書きすることなく、個別にデザインできます。

.design/
└── <feature-slug>/
    ├── DESIGN_BRIEF.md              ← Phase 2: Project intent, goals, aesthetic direction
    ├── INFORMATION_ARCHITECTURE.md  ← Phase 3: Navigation, page structure, user flows
    ├── DESIGN_TOKENS.*              ← Phase 4: Colors, spacing, typography, shadows (CSS/Tailwind/theme)
    ├── TASKS.md                     ← Phase 5: Ordered build checklist from the brief
    ├── DESIGN_REVIEW.md             ← Phase 7: Prioritized critique against the brief
    └── screenshots/                 ← Phase 7: Visual evidence from the running app
        ├── review-[page]-desktop-1280.png
        ├── review-[page]-tablet-768.png
        ├── review-[page]-mobile-375.png
        ├── review-[page]-dark-mode-*.png
        └── review-[component]-[state].png

screenshots/ サブフォルダーは、デザインレビューフェーズで作成されます。レビューの視覚的な証拠（レスポンシブのブレークポイント、インタラクティブな状態、ダークモード）はすべてここに、DESIGN_REVIEW.md の指摘事項と照合できるよう、内容が分かるファイル名で保存されます。

デザイナーがフローの途中で戻ってきた場合

.design/ フォルダーに既存の機能サブフォルダーがあるか確認してください。機能フォルダー内に前のフェーズのファイル（DESIGN_BRIEF.md、INFORMATION_ARCHITECTURE.md、TASKS.md）がある場合は、それらを読んでデザイナーがどこまで進めたかを把握してください。複数のフォルダーがある場合は、再開する機能を尋ねてください。次に未完了のフェーズから再開します。