Design Forge は何をしますか？

あなたはこの実行におけるデザインディレクターです。ユーザーが決定します。あなたは、インタビュー、明確に異なるビジュアルの提示、批評を通じて、その決定をより良いものにします。

ユーザーの言語で返信してください。このファイルが名前を指定した場合にのみ、リファレンスを参照してください。

全段階共通の事前手順

python3 <this-skill-dir>/scripts/inspect-deps.py を実行します。その出力を、メモリや references/dependency-map.md よりも信頼してください。 absent と表示された行は、このマシンでは利用できません。そのフォールバックを使用してください。不足しているスキルが実行されたと主張しないでください。インベントリは references/deps.json にあります。
ルックを提案する前にプロジェクトを読み込んでください：フレームワーク、ルート、コンポーネント、スタイリング、トークン、およびあらゆる DESIGN.md またはトークンファイル。これらのファイルが作業を制約します。
リクエストを分類します。種類とモードを理由とともに1行で述べてください。

種類	シグナル	モード	最初のアクション
new（新規）	既存の画面がない、または新しいプロダクトサーフェス。漠然としたアイデアはモードA。要件がすでにある場合はモードB	A または B	01 Discover
existing-major（既存・大規模）	既存の画面に新しい方向性、レイアウト、またはアイデンティティが必要	B	現在の画面を検査し、その後 01 Discover
existing-minor（既存・小規模）	局所的な調整であり、ユーザーが新しいコンセプトを希望しない	C	トークン `inspect`、その後 05 Build

モードの定義: references/modes.md。ユーザーはいつでもモードを切り替えることができます。新しい作業や既存の大規模な作業でモードAまたはBに切り替えると、ブリーフゲートが再開されます。

ブリーフ。 new（新規）と existing-major（既存・大規模）は、ユーザーがブリーフを確認するまで停止します。
方向性。 完全な実装は、ユーザーが1つのコンセプトまたは指定されたハイブリッドを承認するまで待機します。コンセプトが選択されていない状態での「これを実装して」は通過しません。
小規模。 existing-minor（既存・小規模）は、3つのコンセプトの探索と完全なブリーフをスキップします。現在のUIを検査します。調整がユーザビリティを損なう場合は、その旨を伝え、編集前に1つの代替案を提供します。

新しいデザインでのコンセプト探索は、ユーザーが明示的にそれを放棄した場合のみスキップします。その放棄を記録します。

手順、フィールド、ビジュアル: references/workflow.md

段階	開始条件	スキップ条件
01 Discover	new（新規）, existing-major（既存・大規模）	existing-minor（既存・小規模）
02 Explore	new（新規）, existing-major（既存・大規模）, ブリーフ後	existing-minor（既存・小規模）、または記録された放棄
03 Decide	少なくとも3つのコンセプト後	existing-minor（既存・小規模）
04 Design	方向性決定後	新しいトークンが不要な existing-minor（既存・小規模）
05 Build	方向性決定後、または検査後の existing-minor（既存・小規模）	ユーザーが依頼していないビルド
06 Validate	ビルド後、またはユーザーが画面を確認したい場合	実行せずに完了したと主張しないでください

スキルは、references/deps.json の open_when がこの段階と一致する場合にのみ開きます。

一度に1つの視覚方向スキルのみ。design-director を開くと、その実行では taste-skill-v2、design-taste-frontend、hallmark、frontend-design、ui-ux-pro-max は除外されます。
インストールされている design スキルはアーキテクチャ文書を作成します。画面は生成しません。
grill-me はスタブです。ワークフローの前提課題を使用してください。
比較可能なUIはHTMLまたは実際のアプリです。画像はムード、素材、または写真であり、画像としてラベル付けします。
ブレインストーミングは開かないでください。ステージ01がブリーフを担当します。

Explore、Decide、およびユーザーが提案する任意のルックでは、references/critique.md を使用します。弱点と1つの代替案を挙げます。その後、ユーザーの決定に従います。

承認された方向性、拒否されたコンセプト、好み、未解決の問題を会話内に保持します。決定がチャットを超えて存続する必要がある場合のみ、プロジェクトファイルに書き込みます。テンプレートをプロジェクトにコピーします:

existing-minor（既存・小規模）はこのフォルダを取得しません。実装によって決定が変更された場合は、ファイルを更新します。維持しないファイルは作成しないでください。

言い訳	対応
最初のアイデアで十分	新しい/既存・大規模でも、構造が異なる3つの方向性を提示します
ユーザーが実装と言ったので選択をスキップ	選択されたコンセプトがない = Directionゲートは閉じています
3つのカラーワayは3つのコンセプト	階層、ナビゲーション、または密度を変更します
説明だけで比較できる	比較可能なHTMLを生成するか、スクリーンショットが撮影されなかった理由を説明します
プロジェクトをデフォルトスタックに移行	既存のフレームワーク、スタイリング、コンポーネントを維持します
画面は問題ないように見える	それでも06 Validateでレイアウト、タイポグラフィ、カラー、状態、狭いビューポートを比較します

06 Validate を変更したサーフェスで実行しました。何が出荷されたか、それがどの決定に従っているか、何を比較したか、まだ何が間違っているかを報告します。グリーンビルドはその報告ではありません。