design

Design Skill

$design を使用すると、プロダクトおよび UI の根拠を発見し、設計上重要なコンテキストのギャップだけを埋め、リポジトリの永続的な DESIGN.md 契約を作成または更新できます。これはピクセル一致のループや一回限りのクリティークではなく、継続的に管理される設計ブリーフです。

共有の運用、委任、状態、フック、チーム、キャンセル、検証に関する不変条件は templates/AGENTS.md にあります。ここにルールを重複させず、そのソースに従ってください。

使用するタイミング

• プロダクト、UX、フロントエンド、またはデザインシステムの判断に、リポジトリ内のソース・オブ・トゥルースが必要な場合。
• 機能について、デザイナーのレーンや実装の前に設計ブリーフが必要な場合。
• 既存の UI、アセット、スクリーンショット、制約から実行可能な設計サマリーが必要な場合。

ビジュアルリファレンスの実装一致（$visual-ralph を使用）、スクリーンショットの比較のみ、またはユーザー向けの設計影響がないバックエンド/インフラ作業には使用しないでください。

$visual-ralph との関係

$design は、DESIGN.md におけるプロダクトの目標、ユーザー、情報アーキテクチャ、ビジュアル言語、コンポーネント、アクセシビリティ、制約、未解決の質問を担当します。$visual-ralph は、承認済みのビジュアルリファレンスまたはライブ URL のベースラインに対する実装、測定に基づく判定、ピクセル差分の証拠を担当します。両方が必要な場合は、まず $design を実行してください。DESIGN.md はビジュアル判定の対象を補助するものであり、それに取って代わるものではありません。

ワークフロー

1. ローカルの根拠を発見する

既存の DESIGN.md、デザイン/UX/フロントエンドのドキュメント、README/仕様/Issue、ルート/ページ/レイアウト/コンポーネント/ストーリー、テーマおよびトークンファイル、アセット、スクリーンショット/モックアップ、Storybook または Playwright のベースライン、アクセシビリティ/レスポンシブ/i18n/プラットフォームの制約を確認し、その内容を引用してください。観察事項と推論を区別し、存在しない根拠があれば明記してください。

2. 不足しているコンテキストのみ確認する

リポジトリで解決できないギャップについてのみ、簡潔な質問をしてください。対象は、ユーザーとジョブ、目標と非目標、ブランドの個性と避けるべき美的傾向、主要なフロー、アクセシビリティ/デバイス/ブラウザの対象、入手できないアセットやリファレンスです。回答が得られない場合は、ブロックせずに明示的な前提と未解決の質問を記録してください。

3. DESIGN.md を作成または更新する

有用な内容は残し、矛盾は取り除き、不明点は明記し、判断は実行可能な状態に保ってください。ルートファイルには次のセクションが必要です。

Design

Source of truth

ステータス（Draft | Active | Needs refresh）、日付、プロダクトの対象画面、確認した根拠。

Brand

個性、信頼のシグナル、避けるべきもの。

Product goals

目標、非目標、成功のシグナル。

Personas and jobs

主要なペルソナ、ユーザーのジョブ、利用コンテキスト。

Information architecture

ナビゲーション、ルート/画面、コンテンツの階層。

Design principles

原則とトレードオフ。

Visual language

色、タイポグラフィ、余白、形状/エレベーション、モーション、画像/アイコン。

Components

既存/新規のコンポーネント、バリアント/状態、トークンの所有。

Accessibility

目標とする基準、キーボード/フォーカス、コントラスト、セマンティクス、reduced motion/感覚に関する配慮。

Responsive behavior

ブレークポイント/デバイス、レイアウトの調整、タッチ/ホバーの違い。

Interaction states

読み込み中、空、エラー、成功、無効、該当する場合はオフライン/低速ネットワーク。

Content voice

トーン、用語、マイクロコピーのルール。

Implementation constraints

フレームワーク/スタイリング、トークン、パフォーマンス、互換性、テストおよびスクリーンショットの期待値。

Open questions

[ ] 質問、担当者、影響。

4. 契約を適用する

UI に関する判断の前に、関連する DESIGN.md のセクションを引用し、文書化されたコンポーネントとトークンを再利用してください。実装によって矛盾が明らかになった場合は、ファイルを更新するか、未解決の質問を追加してください。並行するデザインシステムの層を新たに作ってはいけません。

5. 引き継ぎ

通常のフロントエンド作業では、関連するセクション、リポジトリの根拠、受け入れ基準を提供してください。ビジュアルリファレンス、画像、またはライブ URL との一致が対象の場合は、承認済みのベースラインを添えて $visual-ralph に引き継ぎ、DESIGN.md は補助的なコンテキストにすぎないことを明記してください。

根拠と完了条件

設計ドキュメント、アセット、コンポーネント、スクリーンショットを確認したか、存在しないと明記した場合にのみ完了とします。不足しているコンテキストは回答するか、仮定したうえで一覧にします。ルートの DESIGN.md には必要なセクションがすべて含まれている必要があり、推奨事項は DESIGN.md を引用している必要があります。また、Visual Ralph への引き継ぎがある場合は、設計ガバナンスと明確に分けて示します。

Task: {{ARGUMENTS}}