/grill-design
目的: エンドユーザーに対してアプリケーションがどのように見え、動作するかを、確立されたパターンと実際の製品に基づいて定義し、それを永続的に記録すること。
準備（サイレント）
wiki/index.md、wiki/overview.md、wiki/ui-specs/内の関連スペック、schema/design-system.md（存在する場合）を読む。- コード内の既存UI（コンポーネントライブラリ、トークン、Tailwind設定、類似画面）を調査する。
- パターンカタログ を読む。
- 機能に事前の
/grillがなく、ビジネスルールが不確かな場合は、先に/grillを実行することを提案する。
進行ルール
-
一度に一つの質問に、推奨を付けて正当化する。
-
すべてのデザイン質問には具体的な提案を以下の形式で添付する。
**質問:** ユーザーは2,000件の注文をどのようにナビゲートすべきか？ | オプション | パターン | リファレンス（何をコピーするか） | 長所 | 短所 | |---|---|---|---|---| | A ⭐ | データテーブル + ファセットフィルター + 保存済みビュー | **Stripe Dashboard**（フィルターチップがテーブル上に）、**Linear**（サイドバーに保存済みビュー） | スケールする、パワーユーザー向け | モバイルで劣る | | B | マスター詳細 | **Gmail**（リスト＋リーディングペインを並べて表示） | コンテキストが保持される | ワイド画面が必要 | | C | カードグリッド | **Airbnb**（写真付きカード） | 視覚的 | 比較が難しい | **Aを推奨します。** ユーザーは運用担当者でデスクトップ使用が中心であり、ステータスや金額を比較するためです。 -
リファレンスはプロジェクトのドメインに関連する実際のアプリにすべき（フィンテック→Nubank、Stripe、Mercury；プロダクティビティ→Linear、Notion；マーケットプレイス→Airbnb、Mercado Libreなど）。アプリ名だけでなく、何を正確にコピーするか（具体的な詳細）を述べる。
-
エージェントにウェブ検索機能がある場合、例（Mobbin、Page Flows、Dribbble）を検索して提案を強化してもよい。
-
可能な限り、推奨オプションのASCIIワイヤーフレームを示す。
-
既存のデザインシステムを尊重する；変更は明示的にのみ提案する。
次元（関連するものをこの順序でカバーする）
| # | 次元 | 典型的な質問 | 提案すべき一般的なパターン |
|---|---|---|---|
| 1 | ユーザーとコンテキスト | 誰が使う？使用頻度は？デスクトップ/モバイル？技術レベルは？ | —（残りを定義する） |
| 2 | ジャーニー / ユーザーフロー | どこから来て、目的は何で、どこへ行く？ステップは？ | ウィザード、ハブアンドスポーク、リニアフロー |
| 3 | 情報アーキテクチャ | どのような画面がある？階層は？ナビゲーションは？ | サイドバー、タブ、ボトムバー、⌘K、パンくずリスト |
| 4 | レイアウトと視覚的階層 | フォーカルポイントは？密度は？グリッド？レスポンシブ？ | マスター詳細、KPIダッシュボード、分割ビュー |
| 5 | データ表示 | リスト、テーブル、カード、グラフ？検索/フィルター/ソート？ | データテーブル、カンバン、ファセット、保存済みビュー |
| 6 | 作成と編集 | どのように作成/編集する？バリデーション？保存？ | モーダル、ドロワー、インライン編集、自動保存、ステッパー |
| 7 | 状態 | ローディング、空、エラー、成功、部分、権限なし、オフライン | スケルトン、教育的な空状態、元に戻すトースト、楽観的UI |
| 8 | フィードバックとマイクロインタラクション | 確認、遷移、ホバー、ショートカット | トースト、インラインバリデーション、キーボードショートカット |
| 9 | デザインシステムとトークン | ライブラリ（shadcn、Radix、MUI…）？セマンティックカラー、タイポグラフィ、スペーシング、ダークモード | セマンティックトークン、4/8pxスケール |
| 10 | アクセシビリティ | キーボード、フォーカス、コントラストAA、スクリーンリーダー、prefers-reduced-motion | スキップリンク、フォーカスリング、ARIAパターン |
| 11 | コンテンツとトーン | マイクロコピー、言語、トーンオブボイス、エラーメッセージ | — |
| 12 | オンボーディングと活性化 | 初回使用？サンプルデータ？ | チェックリスト、テンプレートギャラリー、サンプルデータ |
統合
テンプレート ui-ux-spec.md に従ってスペックを提示する。以下を含めること：
- 採用パターン の表（パターン → 場所 → リファレンス → 理由）
- リファレンス の表（アプリ → コピーするもの → 避けるべきもの）
- 主要画面のASCIIワイヤーフレーム
- コンポーネントごとの状態マトリックス
- デザインシステムに提案する新しいトークン/ルール
そして記録テーブル：
| 保存先 | ファイル | アクション |
|---|---|---|
| wiki | wiki/ui-specs/<画面-または-フロー>.md | /wiki:add |
| wiki | wiki/concepts/<機能>.md（スペックへのリンク） | /wiki:increment |
| schema | schema/design-system.md | /schema:add（初回）または /schema:increment |
UI実装計画（タスク / チケット）
| タスク | バーティカル | 依存 | 優先度 | アクション |
|---|---|---|---|---|
wiki/tasks/<画面のスラッグ>.md | ui | - | medium | /ticket:new（wiki + issue） |
明示的な承認（ゲート）
「UI/UXスペック、デザインシステムへの記録、タスク作成（+ GitHub issues）を承認しますか？（はい / 調整）」 — 明確な承認なしには何も記録しない。
正式化（承認後）
- /wiki:add →
wiki/ui-specs/<slug>.md（type: ui-spec）。 - 関連する機能/エンティティページに対して/wiki:incrementを実行。
- /schema:addまたは/schema:increment →
schema/design-system.md（テンプレート design-system-rules.md）。 - 計画された各UIタスク（コンポーネント、画面、インタラクション）に対して/ticket:newを実行し、ラベル
vertical:ui（または機能のバーティカル）とstatus:plannedを付ける。 wiki/log.mdに追記：## [YYYY-MM-DD] grill-design | <画面/フロー>と作成したページ・タスクの一覧。- 次のステップを提案する：
/implement <uiタスク>、プロトタイプ、スペックのない隣接画面。