Figmaなしでの製品デザインは、製品がすでに成熟したデザインシステムを持っている場合に機能します。私のAI製品デザインワークフローは三つのエージェントスキルを使用します：ui-designは九つの方向を探り、ui-implementは選択された方向を製品に変換し、ui-walkthroughは内蔵のAgent Browserを通じてすべての状態をレビューします。最終的な決定は私が行い、エージェントは反復的な製作と確認を担当します。
ほとんどの製品機能は白紙の状態から始まるわけではありません。製品がある程度の期間存在すると、その基本的な設計の決定はすでにコードに存在します。ボタン、入力欄、カード、ナビゲーション、間隔、色、コピー、ホバーステート、モバイルでの挙動はすべて定義されています。Figmaでそれらのパーツを再構築するということは、多くの場合、同じコンポーネントを別のキャンバスにドラッグしてから再び製品上で再構築することを意味します。
デザイナーは依然として製品の意思決定を行います。エージェントは、多くの反復的な組み立てや確認作業を取り除きます。これは、Zero がすでにかなり成熟したデザインシステムを持っているため、うまく機能します。
1. デザインシステムを使って、Figmaなしで製品デザインを始める
Figmaなしで作業することは、設計ルールなしで作業することを意味するわけではありません。それにはより明確なルールが必要です。
Zeroについて、エージェントは次の事項を確認できます：
- ボタン、入力、ドロップダウン、カード、ダイアログ、ナビゲーション用の既存コンポーネント
- 確立された間隔、タイポグラフィ、色、境界線、および角の半径
- 既存のホバー、選択、無効、空、モバイルの状態
- 文の先頭のみ大文字にする形式や、ユーザー向けの短いラベルなどのコピーの慣習
- これらのパーツがどのように組み合わされているかを示す実際の画面
これらのリファレンスは、通常のデザインの質問に答えます。新しい入力は、すでに発送されている入力と同じように見えるべきです。新しいカードは、最も近い既存のカードと同じ表面と半径を使用するべきです。アイコンボタンは、他のアイコンボタンと同じホバー時のフィードバックを持つべきです。
これはエージェントに境界を与えます。それは、各画面のために新しい視覚言語を発明することなく、特徴の構造を探ることができます。
Figma は、チームが新しいブランド、新しいコンポーネント システム、または近い製品参照がないインタラクションを作成する場合にも役立ちます。 しかし、システムが成熟すると、実行中の製品が主要なデザイン面になる可能性があります。 これは、Zero の再構築に使用した design-as-code ワークフロー の機能スケール バージョンです。
2. ui-design を使って、9つの製品デザインの方向性を探る
すべての機能はまだ探索が必要です。私は、エージェントが私の最初の文をすぐにコードに変換することを望んでいません。
私はui-designから始めます。私はエージェントに現在の画面、ユーザーの問題、目標、および主な制約を伝えます。エージェントは既存の製品パターンを読み、一つの推奨方向と九つの代替案を返します。
平易な言葉で言えば、このスキルは現在の画面をキャプチャし、1つの推奨方向を作成し、9つの異なる代替案を探り、トレードオフを提示し、人間の選択を待ちます。
この指示の中のデザイン思考
この指示は、単なる視覚的ルールの一覧ではありません。それは、デザイナーの通常のプロセスを繰り返し可能な手順に変えます。
- 提案する前に理解する。 何かを作る前に、現在の画面をキャプチャし、周囲の製品を確認してください。
- システムで考える。 既存のコンポーネント、テンプレートページ、インタラクションパターン、コピーのルールを出発点として扱う。
- 再発明を防ぐ。 AIは、プロンプトが曖昧な場合、新しいパターンを作り出す傾向があります。この指示は、記憶から近似するのではなく、最も近い出荷済みのコンポーネントやページを見つけて再利用するように指示するものです。
- 選ぶ前に探検しよう。 「アフター」アンカーは一つのもっともらしい方向性を示している。九つのバリエーションは、レイアウト、階層、密度、エントリーポイント、開示のさまざまな決定を開く。
- 探索をコミットメントから分ける。 エージェントは選択肢を提示した後で停止する。人間がトレードオフを比較し、コードが開始される前に選択を行う。
- 全体の体験を見直してください。 コピー、ホバーフィードバック、状態、モバイルでの動作、および視覚的一貫性は、実装後のクリーンアップではなく、デザインの一部です。
それが私がそのスキルから求めるシステム思考です：既存の製品を理解し、その中で探求し、そして明示的に選択を行うことです。
こちらが、ライブワークフローから文字通り再現した完全な元の指示です:
ui-design の元の指示全文
# vm0 / Zero UIデザインルール
## ワークフロー — まずビジュアル、後でコード
**すぐにコードを書かないでください。** このスキルが呼び出されたとき、最初に提供されるものは常にMingが確認するためのレンダリングされたモックアップのセットです。方向性が決まった後にのみ実装が行われます。
### ステップ1 — 「前」の状態を撮影する
- 画面がすでに存在する場合は、その現在の状態を**before**画像としてレンダリングします（実行中のアプリをスクリーンショットするか、既存のコンポーネントを静的プレビューとしてレンダリングします）。
- もしリクエストがまったく新しい画面のものであれば、「前」は既存の最も近い画面か、空白の状態になります — キャプションでこれを明確にしてください。
### ステップ2 — 単一の「アフター」アンカーを作成する
- リクエストの最善の推測解釈を表すモックアップの1つで、以下のすべてのルール（コンポーネント、文の大文字小文字、エージェント詳細の入力/ドロップダウン、チャット作成カードの角丸、スケジュール追加ボタン、IconButtonのホバー、gray-50の表面）に完全に従っています。
- それを**前**と並べて組み合わせます。はっきりとラベルを付けてください: `Before` / `After`。
### ステップ3 — 9つのバリアント探索を生成する
ビフォー/アフターのペアの後、同じ画面に対して**9つの異なるバリアントのモックアップ**を作成してください。各バリアントは、意味のある異なるデザインの軸を探求するものであり、単に色を9通りに変えるだけではいけません。次のような範囲をカバーしてください:
1. レイアウト — シングルカラム vs 分割 / サイドバー / グリッド
2. 密度 — コンパクト vs. 広々
3. 階層 — どの要素が視覚的に主導するか
4. 表面処理 — 平面、カードグループ、分割セクション
5. エントリーポイント — インラインアクション vs. 専用CTA vs. 空の状態のヒーロー
6. コピーのフレーミング — 指示的 vs. 最小限 vs. 会話的
7. 開示 — すべてを表示する場合と段階的に表示する場合 / アコーディオン
8. 構成 — コンテンツ主導 vs. コントロール主導
9. 一度は見る価値のある、あえて型破りな／“ワイルドカード”的な方向性
各バリアントは依然として譲れない条件（文の大文字小文字、コンポーネントの再利用、エージェント詳細の入力/ドロップダウンスタイル、チャットコンポーザの角丸、スケジュール追加ボタン、IconButtonのホバー、gray-50のニュートラル）を尊重する必要があります。バリアントは「レイアウトと強調」を探求するものであって、「デザインシステムを無視した場合どうなるか」を検討するものではありません。
### ステップ4 — 提示してから待つ
- すべての画像をミンに一つのメッセージで見せる：最初に`Before / After`のペア、その後、軸を説明する一行キャプション付きで番号1～9の9つのバリエーションを表示する。
- どの方向（またはどのミックス）を進むべきか尋ねる。
- ミンが方向を決めるまで、実施を始めないでください。
### 画像をレンダリングする
- 推奨される方法: `turbo/apps/platform` の実際の Tailwind トークンを使用した静的 HTML/React プレビューを作成し、スクリーンショットを撮って `okou web upload-file` を通じてアップロードすること。
- 素早い探索のために：`v0` スキルはプロンプトからバリアントのモックアップを生成できます — しかし、プロンプトは以下のルール（文頭大文字、エージェント詳細入力、チャットコンポーザーの範囲など）を明確に列挙する必要があり、そうでないと v0 は一般的な SaaS UI を生成してしまいます。
- セッションで画像生成が利用できない場合は、すべての11フレーム（前、後、9つのバリエーション）について、明確にラベル付けされたASCII／テキストワイヤーフレームにフォールバックし、そのことを明記してください — ビジュアルのステップを黙ってスキップすることは絶対に避けてください。
---
# 設計ルール
これらは、vm0プラットフォーム（`turbo/apps/platform`）内で提供される新しいUIにおける交渉不可能なデザイン規約です。コンポーネントの作成前にこれらを適用し、レビュー時には既存のPRがこれらに準拠しているかを監査してください。
## 基本原則
1. **再利用、再発明は避ける。** 新しいコンポーネントを導入する前に、必ず`turbo/apps/platform/src/components/`の既存のプリミティブと`src/views/`のビュー・レベルのパターンを確認してください。類似のインタラクションがすでにエージェント詳細、スケジュール、チャット作成画面で提供されている場合は、並行してデザインするのではなく、そのパターンをコピーしてください。
2. **Zeroのデザイン言語に合わせる。** 柔らかい表面、中立的なグレー、ゆったりとした曲線、さりげない境界線、厳しい影はなし。ビジュアルの基準は「落ち着いていて、意見があり、やや編集的」—決してSaaSのデフォルトではない。
3. **ユーザーの立場から話す。** コピーはシステムが何をしているかではなく、*ユーザーがこれから行うことや目にすること* を説明する。短く保つ — 通常は1文、最大2文まで。
## 参照パターン（これを直接コピーしてください）
| 元素 | 参考資料 | なぜ |
|---------------------|---------------------------------------------------|-----|
| テキスト / テキストエリア入力 | エージェント詳細ページ入力 (`src/views/agent-detail/`) | 確立されたパディング、ボーダー、フォーカス状態、プレースホルダーの処理 |
| ドロップダウン / 選択 | エージェント詳細ページのドロップダウン | 確立されたトリガースタイル、メニューの半径、アイテムのホバー、チェックマークの配置 |
| カード／パネルの半径 | チャット作成カード（`composer`コンポーネントを探してください） | アプリ全体で標準のカードの半径と表面スタイルを設定します |
| 主要ページボタン | スケジュールページの「スケジュール追加」ボタン | モーダルの*外*のすべてで使用されるニュートラルダークプライマリ |
| モーダルのプライマリボタン | ブランドの主要な色（ダイアログ/ポップオーバー内のみ） | モーダルはブランドカラーのプライマリを保持しますが、ページは保持しません |
| アイコンのみのボタン | ホバー背景付きの既存のアイコンボタン | クリック可能なアイコンにはすべて、可視のホバー状態が必要です |
迷ったときは、コードベースのリファレンスコンポーネントを開き、そのpropsやクラス名を読み、それらをそのまま真似してください。記憶からおおよそで行わないでください。
## コピーのガイドライン
- **ユーザー視点の表現。** 「受信箱を接続する」は「受信箱の接続が必要です」より優れています。「まだエージェントはいません」は「エージェントリストは空です」より優れています。
- **完全性より簡潔さ。** 短い一文は、完全な文章よりも効果的です。不要な言葉（「単に」「どうぞ」「～するために」）は削除しましょう。
- **すべてを文章のケースにする。** ラベル、見出し、ボタン、メニュー項目、テーブルの列 — すべて文章のケース（「モデルプロバイダー」「APIキー」「スケジュールを追加」）。タイトルケースにしない。セクション見出しにCSSで`uppercase`を使わない。タイトルケースやすべて大文字のラベルを見つけたら修正する。
- フィールドやセクションの上に「装飾的」なキャプション形式のラベルは使わないでください — それらはフォームっぽく時代遅れに見えます。通常のラベルを使うか、フィールドが自明であればラベルは省略してください。
- **単独のラベルやボタンには末尾の句読点を付けないこと。** 句点は本文や補助テキストで使用する。
- 文字列の名前を変更する場合は、コードベースで古い文字列をgrepし、テストも確認してください — ラベルはテストや翻訳で参照されます。
## コンポーネントと構造
- 常に既存のコンポーネント（`Button`、`Input`、`Select`、`Card`、`IconButton`、ダイアログプリミティブなど）を使ってページを構築してください。新しいコンポーネントは最終手段であり、その理由が必要です。
- 既存のレイアウト／テンプレート（設定ページ、リストページ、詳細ページ）を探して、その足場を継承してください。ページ構造を再作成しないでください。
- 設定スタイルのページに追加する場合は、隣接するセクションで使用されているセクションの間隔、区切りの処理、フォーム行の幅に合わせてください。
## ボタン
- **ページプライマリ**（ページ上の主要なCTA）→ スケジュールページの「スケジュールを追加」ボタンに合わせる。これは、ダイアログ外でアプリ全体で使用されるニュートラルなダーク/ソリッドプライマリです。
- **モーダルプライマリ**（ダイアログ/ポップオーバー内の確認ボタン）→ ブランドのプライマリカラーを使用します。ページでは使用しません。
- **セカンダリー / ゴーストボタン** → 既存のバリアントを再利用してください；新しいものを作らないでください。
- **アイコンボタン** → ホバー時の背景が必要です（通常は `hover:bg-gray-50` または既定の IconButton ホバートークン）。ホバーのないアイコンをクリック対象としてそのまま出荷してはいけません。
- すべてのボタンは既存の高さトークンを尊重する必要があります — 一時的なサイズを導入しないでください。
## 入力
- エージェントの詳細入力を反映させる：同じパディング、同じボーダー、同じフォーカスリング（またはなし — フォーカスリングを追加する前に参照を確認する）、同じプレースホルダーの色。
- 複数行: エージェント詳細のテキストエリアパターンを使用する（参照のように自動拡張または固定行）。
- フィールドラベルの末尾にコロンを付けないでください。
- 入力欄の下の補助テキスト、くすんだ灰色、1行。
## ドロップダウン / セレクト
- エージェント詳細のドロップダウンを反映させる：同じトリガーの外観、同じメニューの角の丸み、同じアイテムのパディング、同じホバー/選択状態。
- メニューは、内容が必要とする場合を除き、トリガーよりも幅が広くなるべきではありません。
- 既存のドロップダウンで既に使用されている場合を除き、入れ子のサブメニューは避けてください。
## カードと表面
- カードの角の半径と表面のスタイルはチャット作成カードに合わせてください。理由がない限り、小さいまたは大きい半径を導入しないでください。
- 境界線は微妙です（既存の境界トークンでは単一のヘアライン）。チャット作成ツールで使用しない限り、ドロップシャドウはありません。
- モバイル上の中立的な表面 / 薄い灰色の塗り（アクティブなピルの背景、アイコンコンテナの塗りなど）→ `bg-gray-50`。`gray-100` と `gray-200` は繰り返し暗すぎると言われている — `gray-50` から始める。
## フォーカスとインタラクション
- ナビゲーションやマーケティング要素にカスタムの`:focus-visible`ボックスシャドウやアウトラインを追加しないでください — 代わりにホバー時の色の変化を再利用してください。（同じ制約は、プラットフォーム内でも、参照コンポーネントに明示的なフォーカスリングがある場合を除き、一般的に適用されます。）
- すべてのインタラクティブ要素（ボタン、アイコンボタン、行、リンク）には、目に見えるホバー状態が必要です。デザインが完成と見なされる前に、各要素をホバーしてテストしてください。
- 無効状態では、既存の無効トークンを使用してください；フェードした色を自作しないでください。
## レビュー・チェックリスト
UI を準備完了と宣言する前に、次の点を確認してください:
1. 新しいコンポーネントを作るのではなく、既存のコンポーネントを再利用しましたか？
2. 既存のページテンプレート／レイアウトに一致しましたか？
3. 入力はエージェントの詳細入力と視覚的に同一ですか？
4. ドロップダウンは、エージェント詳細のドロップダウンと見た目が同じですか？
5. カードはチャット作成ツールの半径と表面に一致しますか？
6. すべてのラベルは文のように大文字小文字が使われていますか？残っているタイトルケースや全て大文字のものはありますか？
7. コピーは短く、ユーザーの立場から書かれていますか？
8. ページのプライマリは「スケジュール追加」スタイルのボタンですか？ブランドのプライマリはモーダル内でのみ使用されますか？
9. すべてのアイコンボタンにホバーバックグラウンドがありますか？
10. すべてのインタラクティブ要素にカーソルを合わせて、フィードバックを確認しましたか？
もしどの答えも「いいえ」であれば、PRを開く前に修正してください。
## 疑わしいときは
- 参照コンポーネントを開き、そのソースを読み、構造をコピーしてください。
- もし二つの参照コンポーネントが意見の不一致を示す場合、より最近出荷されたものを優先してください（git log を確認してください）。
- もし設計が本当に新しいプリミティブを必要とする場合は、構築する前にミンに相談してください — バンドルされた再設計作業は、彼がレビュアーとして1つのPRにまとめるべきです。
9 つのオプションは、9 つの完成したデザインである必要はありません。 彼らの仕事は、問題を違った見方で捉え、正しい方向に進むための十分な範囲を私に与えることです。 コンセプトが現在の製品の範囲外にある場合でも、スタンドアロン React プロトタイプ が役に立ちます。 この機能については、実際の製品システム内に留まりました。
実際の例: Zeroのナビゲーション
Zero には元々、製品の目的地、固定代理店、チャットスレッドを含む1つの300ピクセルのサイドバーがありました。それは同時に3つの役割を果たしていました。私は会話エリアを変更せずに、それらの役割を分けたいと思いました。
探査用の製品概要は次の通りです:
/ui-designZeroの三地域ナビゲーションの設計フェーズを、実際の歴史的ベースから再現してください。会話エリアを変更せずに、製品の目的地、エージェント、会話をより明確な地域に分けてください。実際のZeroのトークン、アイコン、およびコンポーネントを使用してください。原本に忠実な「Before」、1つの強力な「After」、そして9つの本当に異なるバリエーションを作成してください。製品コードを編集したり、モックアップをブラウザ証拠として提示したりしないでください。
最初の探索はあまりにも慎重すぎました。いくつかのオプションで幅や選択スタイルは変わりましたが、それでも同じサイドバーのように見えました。そのセットは却下し、エージェントに情報アーキテクチャのレベルで違いが見えるようにするよう依頼しました。
2回目の実行では、実際に異なる9つの方向が返されました。それらを3×3の表にまとめたので、記事を長い画像ストリップにすることなく比較しやすくなっています。すべてのサムネイルはブログの画像ビューアで開きます。
| 1. トップナビゲーション | 2. 折りたたみ式引き出し | 3. スレッドを最初に |
|---|---|---|
 |  |  |
| 会話の上に目的地を移動する | 必要になるまで目的地を隠す | 会話を主要なナビゲーションオブジェクトにする |
| 4. エージェントを優先 | 5. 会話を優先する | 6. コマンドランチャー |
 |  |  |
| スレッドの前にエージェントを選択してください | 固定されたエージェントをアクティブな会話の上に置く | 検索可能なメニューから目的地を開く |
| 7. 拡張可能なレール | 8. ダッシュボードのエントリー | 9. 下部ドック |
 |  |  |
| 狭いレールは必要なときだけ拡張する | 最近の作業から始める | 目的地を下に移動する |
私はこれらのフレームのどれかをそのまま選んだわけではありません。どこを残し、どこを変更するかを決めるために使用しました。最終的な方向性では、狭い目的地用レール、別のチャット用レール、5つの表示された固定エージェント、そして既存の会話エリアが使用されました。
ui-designの重要な出力は、単なる画像ではありませんでした。それは短い決定記録でした:
- 68ピクセルの目的地レールと300ピクセルのチャットレールを維持してください
- ピン留めされたエージェントスロットを5つ表示
- 選択部分を静かに保ちつつ、読みやすくする
- ドラッグ中のみ並べ替えガイドを表示
- 会話と既存のモバイルドロワーは変更せずに保持してください
それで実施を始めるのに十分だった。
3. 選択したデザインをコードに変換するには、ui-implementを使用します
方向を選んで製品のコードベースに接続した後、エージェントは直接コード内で作業します。最初にFigmaで選択したフレームを描き直すことはありません。
平易な言葉で言えば、ui-implementは方向がすでに選ばれているため探索をスキップします。最も近い実際のコンポーネントとページ構造を見つけ、それらで構築し、結果を監査し、ブラウザで機能を検証します。
この指示が保護するもの
- 選ばれた方向性は、実装中に再設計されてはいけません。
- エージェントは、最も近い既存のコンポーネントとテンプレートページから始めなければなりません。
- 製品に実際のギャップがない限り、新しい部品よりも再利用が勝る。
- セルフ監査とブラウザチェックは、不一致のコピー、状態、およびインタラクションを検出します。
- 製品の決定がまだ unresolved の場合、作業は
ui-designに戻ります。
これが、デザインシステムが実装中にアクティブであり続ける方法です。それはエージェントが一度読むだけの文書ではありません。それは、どのコンポーネントを選ぶか、そして完成した体験をどのように確認するかを形作ります。
こちらが、ライブワークフローから文字通り再現した完全な元の指示です:
ui-implement の元の指示全文
# vm0 / Zero UI実装規則
## ワークフロー — 直接実装する
このスキルが発動されたとき、**モックアップおよびバリアント探索のフェーズをスキップ**してください。以下のすべての設計ルールを適用しながら、`turbo/apps/platform`での実装を直ちに開始します。
### ステップ1 — 参照コンポーネントを探す
行を書く前に、参照するコンポーネントを開きます:
- 入力 / テキストエリア → `src/views/agent-detail/` 入力
- ドロップダウン / 選択 → `src/views/agent-detail/` ドロップダウン
- カード / パネルの半径 → チャット作成カード
- ページの主要なボタン → スケジュールページの「スケジュールを追加」ボタン
- アイコンのみのボタン → ホバー時の背景付き既存の `IconButton`
彼らのプロップとクラス名を読んでください。それらを鏡のように真似してください — 記憶からおおよそで近似しないでください。
### ステップ2 — 最も近い既存のページテンプレートを見つける
同じ形状の最も近い既存のページ（設定、リスト、詳細）を開き、そのスキャフォールディングを継承します：セクションの間隔、区切り線の処理、フォーム行の幅。ページ構造を再導出してはいけません。
### ステップ3 — 構築してから自己監査する
`turbo/apps/platform/src/components/`の既存プリミティブを使って画面を実装してください。完了したと思ったら、報告する前にこのスキルの下部にある**レビュー・チェックリスト**を確認してください。作業完了を宣言する前に、すべての「いいえ」の答えを修正してください。
### ステップ4 — ブラウザで確認する
UI関連の作業については、タスクを完了として報告する前に、開発サーバーを起動し、ブラウザで機能を確認してください。すべてのインタラクティブ要素にホバーし、基本的な操作フローやエッジケースをテストし、隣接する画面でのリグレッションに注意してください。型チェックやテストはコードを検証するものであり、機能の正確性を確認するものではありません — ブラウザを開けない場合は、その旨を明確に伝えてください。
### ui-designにフォールバックするタイミング
要求がオープンエンド（「Xの設定ページをデザインする」など）で、方向性が決まっていない場合は、停止して`ui-design`スキルを実行してください — before/after + 9のバリエーションはまさにそのケースのために存在します。方向性がすでに決まっている場合は`ui-implement`を使用します。
---
# 設計ルール
これらは、vm0プラットフォーム（`turbo/apps/platform`）内で出荷される新しいUIに対する譲れないデザイン規約です。構築時にはこれらを適用し、PRを開く前に自身の差分をこれらに照らして確認してください。
## 基本原則
1. **再利用、再発明は避ける。** 新しいコンポーネントを導入する前に、必ず`turbo/apps/platform/src/components/`の既存のプリミティブと`src/views/`のビュー・レベルのパターンを確認してください。類似のインタラクションがすでにエージェント詳細、スケジュール、またはチャット作成で提供されている場合は、並行するデザインを作るのではなく、そのパターンをコピーしてください。
2. **Zeroのデザイン言語に合わせる。** 柔らかい表面、ニュートラルグレー、広めの半径、控えめなボーダー、強い影はなし。ビジュアルの基準は「落ち着いていて、意見があり、やや編集的」—決してSaaSのデフォルトではない。
3. **ユーザーの立場から話す。** コピーはシステムが何をしているかではなく、*ユーザーがこれから行うことや目にすること* を説明する。短く保つ — 通常は1文、最大2文まで。
## 参照パターン（これを直接コピーしてください）
| 元素 | 参考資料 | なぜ |
|---------------------|---------------------------------------------------|-----|
| テキスト / テキストエリア入力 | エージェント詳細ページ入力 (`src/views/agent-detail/`) | 確立されたパディング、ボーダー、フォーカス状態、プレースホルダーの処理 |
| ドロップダウン / 選択 | エージェント詳細ページのドロップダウン | 確立されたトリガースタイル、メニューの半径、アイテムのホバー、チェックマークの配置 |
| カード／パネルの半径 | チャット作成カード（`composer`コンポーネントを探してください） | アプリ全体で標準のカードの半径と表面スタイルを設定します |
| 主要ページボタン | スケジュールページの「スケジュール追加」ボタン | モーダルの*外*のすべてで使用されるニュートラルダークプライマリ |
| モーダルのプライマリボタン | ブランドの主要な色（ダイアログ/ポップオーバー内のみ） | モーダルはブランドカラーのプライマリを保持しますが、ページは保持しません |
| アイコンのみのボタン | ホバー背景付きの既存のアイコンボタン | クリック可能なアイコンにはすべて、可視のホバー状態が必要です |
迷ったときは、コードベースのリファレンスコンポーネントを開き、そのpropsやクラス名を読み、それらをそのまま真似してください。記憶からおおよそで行わないでください。
## コピーのガイドライン
- **ユーザー視点の表現。** 「受信箱を接続する」は「受信箱の接続が必要です」より優れています。「まだエージェントはいません」は「エージェントリストは空です」より優れています。
- **完全性より簡潔さ。** 短い一文は、完全な文章よりも効果的です。不要な言葉（「単に」「どうぞ」「～するために」）は削除しましょう。
- **すべてを文章のケースにする。** ラベル、見出し、ボタン、メニュー項目、テーブルの列 — すべて文章のケース（「モデルプロバイダー」「APIキー」「スケジュールを追加」）。タイトルケースにしない。セクションの見出しにCSSで`uppercase`を適用しない。タイトルケースやすべて大文字のラベルを見つけた場合は、修正する。
- フィールドやセクションの上に「装飾的」なキャプション形式のラベルは使わないでください — それらはフォームっぽく時代遅れに見えます。通常のラベルを使うか、フィールドが自明であればラベルは省略してください。
- **単独のラベルやボタンには末尾の句読点を付けないこと。** 句点は本文や補助テキストで使用する。
- 文字列の名前を変更する場合は、コードベースで古い文字列をgrepし、テストも確認してください — ラベルはテストや翻訳で参照されます。
## コンポーネントと構造
- 常に既存のコンポーネント（`Button`、`Input`、`Select`、`Card`、`IconButton`、ダイアログのプリミティブなど）からページを作成してください。新しいコンポーネントは最後の手段であり、理由が必要です。
- 既存のレイアウト／テンプレート（設定ページ、リストページ、詳細ページ）を探して、その足場を継承してください。ページ構造を再作成しないでください。
- 設定スタイルのページに追加する場合は、隣接するセクションで使用されているセクションの間隔、区切りの処理、フォーム行の幅に合わせてください。
## ボタン
- **ページプライマリ**（ページ上の主要なCTA）→ スケジュールページの「スケジュールを追加」ボタンに合わせる。これは、ダイアログ外でアプリ全体で使用されるニュートラルなダーク/ソリッドプライマリです。
- **モーダルプライマリ**（ダイアログ/ポップオーバー内の確認ボタン）→ ブランドのプライマリカラーを使用します。ページでは使用しません。
- **セカンダリー / ゴーストボタン** → 既存のバリアントを再利用してください；新しいものを作らないでください。
- **アイコンボタン** → ホバー時の背景が必要です（通常は `hover:bg-gray-50` または既定の IconButton ホバートークン）。ホバーのないアイコンをクリック対象としてそのまま出荷してはいけません。
- すべてのボタンは既存の高さトークンを尊重する必要があります — 一時的なサイズを導入しないでください。
## 入力
- エージェントの詳細入力を反映させる：同じパディング、同じボーダー、同じフォーカスリング（またはなし — フォーカスリングを追加する前に参照を確認する）、同じプレースホルダーの色。
- 複数行: エージェント詳細のテキストエリアパターンを使用する（参照のように自動拡張または固定行）。
- フィールドラベルの末尾にコロンを付けないでください。
- 入力欄の下の補助テキスト、くすんだ灰色、1行。
## ドロップダウン / セレクト
- エージェント詳細のドロップダウンを反映させる：同じトリガーの外観、同じメニューの角の丸み、同じアイテムのパディング、同じホバー/選択状態。
- メニューは、内容が必要とする場合を除き、トリガーよりも幅が広くなるべきではありません。
- 既存のドロップダウンで既に使用されている場合を除き、入れ子のサブメニューは避けてください。
## カードと表面
- カードの角の半径と表面のスタイルはチャット作成カードに合わせてください。理由がない限り、小さいまたは大きい半径を導入しないでください。
- 境界線は微妙です（既存の境界トークンでは単一のヘアライン）。チャット作成ツールで使用しない限り、ドロップシャドウはありません。
- モバイルのニュートラルな表面 / ライトグレーの塗り（アクティブピルの背景、アイコンコンテナの塗りなど） → `bg-gray-50`。`gray-100` と `gray-200` は繰り返し暗すぎると言われているため、`gray-50` から開始してください。
## フォーカスとインタラクション
- ナビゲーションやマーケティング要素にカスタムの`:focus-visible`ボックスシャドウやアウトラインを追加しないでください — 代わりにホバー時の色の変化を再利用してください。（同じ制約は、プラットフォーム内でも、参照コンポーネントに明示的なフォーカスリングがある場合を除き、一般的に適用されます。）
- すべてのインタラクティブ要素（ボタン、アイコンボタン、行、リンク）には、目に見えるホバー状態が必要です。デザインが完成と見なされる前に、各要素をホバーしてテストしてください。
- 無効状態では、既存の無効トークンを使用してください；フェードした色を自作しないでください。
## レビュー・チェックリスト
UI を準備完了と宣言する前に、次の点を確認してください:
1. 新しいコンポーネントを作るのではなく、既存のコンポーネントを再利用しましたか？
2. 既存のページテンプレート／レイアウトに一致しましたか？
3. 入力はエージェントの詳細入力と視覚的に同一ですか？
4. ドロップダウンは、エージェント詳細のドロップダウンと見た目が同じですか？
5. カードはチャット作成ツールの半径と表面に一致しますか？
6. すべてのラベルは文のように大文字小文字が使われていますか？残っているタイトルケースや全て大文字のものはありますか？
7. コピーは短く、ユーザーの立場から書かれていますか？
8. ページのプライマリは「スケジュール追加」スタイルのボタンですか？ブランドのプライマリはモーダル内でのみ使用されますか？
9. すべてのアイコンボタンにホバーバックグラウンドがありますか？
10. ブラウザのすべてのインタラクティブ要素にカーソルを合わせてフィードバックを確認しましたか？
もしどの答えも「いいえ」であれば、PRを開く前に修正してください。
## 疑わしいときは
- 参照コンポーネントを開き、そのソースを読み、構造をコピーしてください。
- もし二つの参照コンポーネントが意見の不一致を示す場合、より最近出荷されたものを優先してください（git log を確認してください）。
- もし設計が本当に新しいプリミティブを必要とする場合は、構築する前にミンに相談してください — バンドルされた再設計作業は、彼がレビュアーとして1つのPRにまとめるべきです。
これは機能固有の実装プロンプトでした:
/ui-implement
04d642bbのリビジョンから開始します。デフォルトオフのデスクトップ分割を追加し、68px の宛先レール、300px のチャットレール、変更なしの会話を設定します。スイッチがオフの場合やモバイルでは、古い 300px のサイドバーを維持します。固定された 5 つのスロットをレンダリングし、ユーザー定義の順序を保持し、アクティブなドラッグ中のみ並べ替え用の操作を表示します。独立したパッチ、テスト、およびブラウザの証拠が確定するまで、履歴機能やその後の改良を確認しないでください。
ナビゲーション機能について、機能がオフのときは既存のサイドバーを保持し、オンのときは新しい三分割レイアウトを表示し、既存のモバイルドロワーを保持し、ユーザーが固定されたエージェントを並べ替えできるようにするようにエージェントに依頼しました。
実装中、エージェントは1つの重要な問題を発見しました。古い製品はどのエージェントが固定されたかを記憶していましたが、その順序は記憶していませんでした。ドラッグ操作は正しく見える場合がありますが、更新後にリセットされることがあります。
つまり、エージェントはドラッグ状態を描画する以上のことを行いました。新しい注文を保持させ、ページをリフレッシュし、注文が保持されていることを確認しました。また、並べ替えハンドルがドラッグ中のみ表示され、その後消えることも確認しました。
実装の配信では、私が確認する必要のあった2つのデスクトップ状態が表示されました。インターフェースを読みやすく保つために、これらをフル幅で表示しています。モバイルの挙動は、ウォークスルーの後半で高密度の電話キャプチャとして登場します。
デスクトップ休止状態
アクティブな再注文
この時点で私は動作する機能を持っていましたが、別のデザインファイルではありませんでした。しかし、実装はまだ終わりではありませんでした。実際にデプロイされたプレビューで何が動いているのかを確認する必要がありました。
4. 実際の製品を確認するには、ui-walkthrough を使用してください
製品のウォークスルーは以前は面倒でした。デプロイされたプレビューを開き、適切なアカウントを準備し、機能のオンとオフを切り替え、すべてのコントロールをクリックし、ブラウザのサイズを変更し、スクリーンショットを撮り、各画像がどの状態を表しているかを覚えようとしていました。
そのエージェントには内蔵のAgent Browserがあるので、その作業をそれに任せることができます。
その作業フローには二つの主要なステップがあります:
- まずシナリオをリストアップします。 エージェントは設計と実装の主張をチェックリストに変えます。
- チェックリストを実行して証拠を添付してください。 デプロイされたプレビュー内のすべてのシナリオを実行し、各意味のある状態のスクリーンショットとともに PASS、FAIL、または BLOCKED を返します。
この指示がレビューに関して変更すること
- エージェントはクリックを開始する前にシナリオをリストアップします。
- それは内蔵の Agent Browser を通じて、実際にデプロイされたコンポーネントを使用します。
- それは、各意味のある状態ごとに1つのスクリーンショットをキャプチャします。
- これは、チェックポイント PASS、FAIL、または BLOCKED のすべてに印を付けます。
- 利用できない状態を偽の証拠の背後に隠すことは決してありません。
これにより、手動でのクリックが整理されたレビュー・パッケージになります。意図した動作、結果、証拠を一緒に確認することができます。
以下に完全な指示を示します。読者向けの明確さのために、内部依存関係名を「組み込み Agent Browser」と翻訳しました。それ以外のワークフローロジックは変更されていません。
ui-walkthrough の元の指示全文
# UIウォークスルー
vm0/Zero フロントエンド機能の実際のプルリクエストごとのプレビューでのエンドツーエンドのビジュアルQA。このワークフローは、何を確認し、どのように結果を報告するかを定義します。UI操作ツールは定義しません。
## 必要な依存関係: 組み込み Agent Browser
すべてのUI操作の単一の信頼できる情報源として、組み込みのAgent Browserを使用してください。これには以下が含まれます:
- PRごとのプレビューを発見して開くこと。
- プレビュー保護の処理とセッションの設定。
- サインアップ、OTP、オンボーディング、Stripeテストチェックアウト、そしてライブアプリへの到達。
- 機能スイッチを有効にする。
- ナビゲート、コントロールとの操作、テストやモックデータの提供、スクリーンショットの取得、アーティファクトのアップロード、トラブルシューティング、そしてクリーンアップ。
UI操作を行う前に、現在の組み込みAgent Browserの指示を読み、従ってください。ランタイム固有のコマンド、エンジン設定、セレクタの仕組み、ページコンテキストスクリプト、セッション管理、またはプロセスのクリーンアップ方法をこのワークフローで重複させないでください。組み込みAgent Browserが変更された場合、その現在の指示が優先されます。
## いつ使うか
- デプロイされたプレビューでの vm0 プルリクエストの UI を確認する。
- 認証、オンボーディング、請求、機能スイッチ、または実際のチャットスレッドを必要とするアプリ内機能を確認してください。
- 実際のアプリケーションで機能が動作している様子を忠実にスクリーンショットや短いウォークスルービデオで記録してください。
## ウォークスルーワークフロー
### 1. 目標と範囲を設定する
- PR、ヘッドコミット、変更されたユーザー向けの動作、および期待されるプレビューを特定します。
- テストする前に、デプロイされたプレビューがPRの先頭に対応していることを確認してください。
- PRの差分と説明を読んで、重要な経路と変更を示す状態を導き出してください。
- ウォークスルー中に、ユーザーが別途実装を要求しない限り、コードの修正、コンフリクトの解消、または製品の動作変更を行わないでください。
### 2. 機能に到達する
内蔵の Agent Browser を使用してプレビューに入り、ライブ機能状態に到達してください。認証、オンボーディング、請求、機能スイッチ、プレビュー専用のバイパスについては、現在のルールに従ってください。
バイパスを使用する場合は、最終報告書で開示してください。オンボーディング自体がテスト中の場合には、オンボーディング用バイパスを使用してはいけません。
### 3. ビジュアルステートマトリックスを定義する
やり取りする前に、その機能が動作することを証明する最小限の状態のセットをリストしてください。該当する項目を含めてください:
- 初期/デフォルトの状態。
- 開いている、ホバー、フォーカス、選択済み、展開済み、またはアクティブな状態。
- 空の状態とデータがある状態。
- 有効および無効の状態。
- 成功、確認、読み込み、およびエラーの状態。
- 配置、衝突、反転、クリッピング、そしてレスポンシブな挙動。
- 機能がインタラクティブな場合の送信または下流のアクション。
一般的なスモークテストよりも、実際に変化した行動を実践することを好む。
### 4. ライブコンポーネントを駆動する
すべてのインタラクションおよびテストデータの手法には、組み込みのAgent Browserを使用してください。
モックまたは注入されたコンテンツは、実際のアプリケーションコンポーネントを決定論的な視覚状態に配置するためにのみ使用できます。評価されるコンポーネント、スタイリング、インタラクションは、PRプレビューのライブ実装のままである必要があります。
モックされた状態ごとに：
- どのコンテンツまたは前提条件が模倣されたかを記録する。
- モックされたコンテンツと実際のアプリケーションの動作を区別する。
- モックされたテキストやデータがモデルや本番ソースから来たと示唆してはいけません。
- 環境が許す限り、実際の操作装置と下流の配線を操作してください。
### 5. 証拠を記録する
主要なチェックポイントの証拠をキャプチャしてアップロードするには、組み込みの Agent Browser を使用してください。各画像は同じビューを繰り返すのではなく、1つの意味のある状態を証明する必要があります。
ユーザーが動画を要求した場合、検証済みのチェックポイントから短い字幕付きのウォークスルーを作成してください。字幕には、ユーザーの操作と期待される結果を、UIを隠さずに示す必要があります。
### 6. 提出して報告する
報告:
- PRリンク、正確なプレビューURL、および可能な場合はテスト済みコミット。
- 正確なユーザーフローが実行されました。
- アカウントが作成されたときのテスト。
- 各チェックポイントに対して、`PASS`、`FAIL`、または `BLOCKED`。
- スクリーンショットのリンクと、短い説明付きの任意のビデオリンク。
- 機能スイッチ、バイパス、モックデータ、その他のテスト専用設定が使用されました。
- チェックの失敗、環境の障害、または検証のギャップ。
ライブプレビューのフローが実行され、証拠が記録されていない限り、その機能が検証済みであると主張しないでください。プレビューが利用できない場合は、ローカルまたは静的なレプリカで代用するのではなく、デプロイメントの証拠とともに`BLOCKED`を報告してください。
これは機能別のウォークスルーのプロンプトでした：
/ui-walkthrough組み込みのAgent Browserを通じて展開されたプレビューを唯一のブラウザの真実として使用してください。機能オフのサイドバー、68pxと300pxの分割、宛先順序、ホバーステート、5つの固定スロット、ドラッグ専用ハンドル、永続化された並べ替え、スレッド選択、スクロール、および完全なiPhoneドロワーを証明してください。各チェックポイントごとにPASS、FAIL、またはBLOCKEDを返してください。到達不能な状態をレプリカで置き換えないでください。
この機能に関して、エージェントはこれらの質問を中心にウォークスルーを整理しました：
- 機能がオフのとき、古いサイドバーはまだ動作しますか？
- 電源が入っているときに新しいデスクトップの構造は表示されますか？
- ホバー状態と選択状態は見えるが控えめですか？
- 5つのピン留めされたエージェントは読めますか？
- 並べ替えコントロールは、ドラッグが始まるまで隠れたままですか？
- 新しい注文はリフレッシュに耐えられますか？
- 実際のスレッドを選択してスクロールできますか？
- 既存のモバイルドロワーはまだ動作しますか？
- すべてのナビゲーション先は存在しており、正しい順序になっていますか？
エージェントはその後、新しいユーザーとして展開されたプレビューを開き、オンボーディングを完了し、機能を有効にし、リストを順に処理しました。静止状態、ホバー状態、ドラッグ状態、更新動作、スレッド選択、スクロール、および電話レイアウトをテストしました。
結果は 11 PASS、1 FAIL でした。
その失敗は役に立った。レイアウトとインタラクションは機能したが、デプロイされたプレビューには6つの製品の行き先しか表示されなかった。ActivityとInsightsが欠落しており、順序も選択したデザインと一致していなかった。
| シナリオ | 結果 |
|---|---|
| 機能がオフの古いサイドバー | PASS |
| 新しい3分割デスクトップレイアウト | PASS |
| ホバーおよび選択状態 | PASS |
| 5人の固定されたエージェント | PASS |
| ドラッグのみの並べ替えガイド | PASS |
| 更新後に保存された注文 | PASS |
| スレッドの選択とスクロール | PASS |
| 既存のモバイルドロワー | PASS |
| 宛先の内容と順序 | FAIL |
最終的な納品物は、ラベルのない画像のフォルダではなく、整理されたスクリーンショットのセットでした。デスクトップのキャプチャは1440×900ピクセルで、電話のキャプチャは1170×2532ピクセルです。インターフェースが読みやすいよう、下に1枚ずつ表示されます。記事を離れずに画像を拡大するには、任意の画像をクリックしてください。
機能オフ
機能が有効になりました
デスクトップレイアウト
目的地ホバー
ピン留めされたエージェントのホバー
アクティブドラッグ
保存された注文
移動式引き出し
これにより、機能を体系的にレビューすることができます。意図されたシナリオ、実際に展開された結果、そして証拠を一緒に確認できます。もし何かが失敗した場合、作業が正確にどこに戻るべきかがわかります。
チームがこのAI製品デザインのワークフローを採用する方法
完全なプロセスは短いです。 チームメイトは、メモリからプロセスを再構築する代わりに、各ステージを 共有 Zero ワークフロー として保存できます。
| ステージ | 入力 | 出力 |
|---|---|---|
ui-design | 現在の画面、問題、目標、制約 | 推奨される方向性1つ、代替案9つ、選択された設計記録 |
ui-implement | 選択された設計記録 | 確認可能なコード変更と主要な状態のスクリーンショット |
ui-walkthrough | 展開された機能とその期待される動作 | PASS、FAIL、またはBLOCKEDのスクリーンショット付きの整理されたシナリオリスト |
チームメイトは私のデザインの好みを再現する必要はありません。 適切なコンテキストを提供し、共有製品システムを使用し、探索後に明示的に選択し、ブラウザーの証拠を確認する必要があります。 同じ 3 つの人間のチェックポイント (問題、方向性、受容) が、私たちの AI エージェントをチームのように管理する のあり方も形作ります。
このワークフローはデザインの実践やデザイン思考を取り除くものではありません。それらを最も重要な部分に移動させます：問題の定義、制約の設定、方向性の比較、トレードオフの選択、そして稼働中の製品の判断です。
コンポーネントシステムが成熟すると、Figmaで全ての機能をドラaggableブロックとして再構築する必要はなくなります。私は製品内で直接エージェントと作業でき、デザインシステムは出力を一貫させ、ウォークスルーは結果を正直に保ちます。
よくある質問
AIプロダクトデザインのワークフローはどのように構築しますか？
空白のプロンプトではなく、既存の製品システムから始める。作業を探索、実装、レビューに分ける。エージェントに選択肢を生成させ、繰り返しチェックを行わせるが、製品デザイナーが問題、選択した方向、最終的な承認に責任を持つようにする。
製品デザイナーはFigmaなしで作業できますか？
はい、製品ですでに安定したコンポーネント、ページテンプレート、インタラクションパターンがある場合にはそうです。Figmaは、新しいビジュアル言語やなじみのないインタラクションでも有用です。重要なのはFigmaを禁止することではなく、既知の製品上の決定を別のキャンバスで再構築することを避けることです。
AIは製品デザイナーに取って代わっているのですか？
このワークフローでは違います。エージェントはオプションを組み立て、コードを編集し、シナリオを確認します。デザイナーは依然として問題を定義し、制約を設定し、トレードオフを比較し、方向性を選択し、実際に動作する製品が出荷に十分かどうかを判断します。
