charlesbot/android-design-explore

ビジュアルデザインの探索

すべてのデザイン決定においてandroid-designスキルに従ってください。そのセクション0の回答、コンポーネント、テーマ設定、レイアウト、画面チェックの質問が含まれます。このスキルがワークフローを所有します。各実行は1回限りです。つまり、簡単な説明を入力し、1つの提案を作成し、チェックし、表示してから停止します。スマートフォン、折りたたみ端末、タブレット、デスクトップ、Wear OSのアプリ画面が対象範囲です。Wearタイル、文字盤、ウィジェットは対象外です。Wearが異なる部分については、以下のWear OSセクションで説明します。

提案はデータファイルであり、プレビューアプリ（ネイティブのmacOSウィンドウ）が実際のCompose Material 3コンポーネントで描画し、保存するたびに再描画します。アプリのレイアウトツリーを通じてチェックします。ユーザーはウィンドウで見た目を評価します。

要件

macOSであり、プレビューアプリがインストールされ、android_design_previewという名前のMCPサーバーとして登録されている必要があります。最初にそのstatusツールを呼び出してください。ツールが利用できない場合は、停止してユーザーに次の2つの手順を説明し、その後待機します。

1. android-designリポジトリのチェックアウトからアプリをビルドしてインストールします: cd app && ./gradlew :app:installApp これにより~/Applications/AndroidDesignPreview.appがインストールされます。
2. ハーネスに登録し、セッションを再起動します（<binary>は~/Applications/AndroidDesignPreview.app/Contents/MacOS/AndroidDesignPreviewであり、ハーネスが~を展開しない絶対パスとして記述します）。
   • Claude Code: claude mcp add --scope user android_design_preview -- <binary>
   • Codex: ~/.codex/config.tomlに[mcp_servers.android_design_preview]テーブルを作成し、command = "<binary>"とdefault_tools_approval_mode = "approve"を設定します。
   • Antigravity: agy mcp add android_design_preview <binary>

簡単な説明

アプリが存在する場合、まず関連する画面、テーマ、アセット、既存のDESIGN.mdとdesign/内の提案を読み込みます。返信でandroid-designのセクション0に回答します。

• 1つのシードを選択します: ブランドカラー、または対象（料理、アルバム、旅行など）からコンテンツカラーを選びます。アプリのデフォルト#6750A4は使用しないでください。
• 画面がヒーローモーメント（セクション0の質問3）である場合、3つ以上の戦術（セクション3）を重ねて名前を付けます。
• アプリのコードと依存関係は変更しないでください。
• 代表的で機密性のないデータとアセットを使用します。画像生成は提案内のアセットに対してのみ使用し、提案の代わりとして使用しないでください。

ユーザーが明示的に要求した場合のみ、複数の提案を作成します。各提案は独自のファイルであり、独自のテーマに独自のシードを持つ、明確に異なる構成（色の変更ではない）であり、少なくとも1つはヒーローです。

ファイル

アプリのリポジトリルート、またはユーザーが指定したフォルダーで作業します。このスキル自身のリポジトリに書き込まないでください。

• ルートにあるDESIGN.mdは共有デザインシステムを保持します。存在しない場合は、選択したシード、フォント、名前付きスタイルで作成します。方向性がすべての提案で共有するものを変更する場合のみ変更します。方向性独自の外観は、その提案のthemeに含めます。
• design/<slug>.proposal.jsonは1つの提案を保持します。

どちらも通常の追跡対象ファイルであり、コミットはプロジェクト独自のワークフローに従います。提案の絶対パスをユーザーに伝えてください。

作成

1. get_catalogを呼び出します（ツールの説明に戻り値が記載されています）。これは唯一のコンポーネント語彙です。足りないコンポーネントは使用できないため、Box、Row、Column、Text、Shapeからアイデアを構築するか、省略します。
2. references/proposal-format.mdを読み、その後DESIGN.mdと提案を、その「コンパクトに書く」セクションの指示に従ってコンパクトに記述します。

提案には次のデザインルールが含まれます。proposal-format.mdに各ルールの構文が記載されており、コンポーネントルールセクションにはタブ、カルーセル、オーバーレイ、選択肢、ツールバー、メニュー、アプリバー、バッジのルールが記載されています。

• 画面にはプライマリアクションが1つあり、プライマリとしてマークされ、android-designセクション2の説明に従って、同等のアクションよりも優先されます。
• 600dpと840dpで適応します。コンパクトではナビゲーションバー、ミディアム以上ではレールになり、リストの詳細画面は拡張幅でリストの横に開きます。
• テキストは省略記号で意図的に切り詰めます。ボタン、チップ、ナビゲーションラベルは1行に収めます。

チェック

提案の場合、このステップはandroid-designの画面チェックにおけるレンダリングを置き換えます。check_proposalのレイアウトサマリーとエラー（およびそれだけでは不十分な場合のget_tree）から質問に回答します。レンダリングやピクセルからは回答しません。スクリーンショットはこのループに含めません。スクリーンショットを撮ったり、要求したりしないでください。

1. 提案の絶対パスを指定してopen_proposalを呼び出します。ファイルをロードし、監視し、ウィンドウを表示し、バリデーションエラーを返します。エラーを修正し、エラーがなくなるまでstatusを呼び出します。
2. check_proposalを呼び出します。1回の呼び出しですべての画面をすべてのビューでチェックし、各ビューのエラーとlayoutサマリーを返します。ツールの説明にフォーマットが記載されています。
3. すべてのエラーを1回修正し、再度check_proposalを呼び出します。overflowエラーは、ノードが親またはビューよりも広くレイアウトされていることを示します（セルよりも幅が必要な行）。狭くするか、折り返すか、スクロール可能にします。ループせずに、まだ失敗しているものを報告します。
4. layoutサマリーから適応を確認します。各大きなビューは、セクション0の適応回答で約束した内容（2番目のペイン、レール、またはより多くのリージョンなど）を明らかにします。Google: 「追加のスペースは、単に同じものを大きくすることを意味するわけではありません。」電話のリージョンだけがより広く広がっている大きなビューは不合格です。
5. サマリーまたはエラーだけでは不十分な場合にのみget_treeを呼び出します。ツールの説明に戻り値が記載されています。

このステップは、check_proposalが合格するか、残っている各エラーが報告するリストに含まれ、適応が確認されたときに完了します。

表示

show_previewを呼び出します。1行で提案の内容を説明し、ヒーローが重ねる戦術に名前を付け、未解決の指摘事項をリストし、「レイアウトツリーからのみ判断されたビジュアル品質」と報告します。その後停止し、ユーザーの返信を待ちます。

修正

ユーザーのフィードバックに基づいて同じ提案を編集します。保存するとウィンドウが再描画されます。変更した画面を再度チェックします。修正は古いバージョンを置き換えます。コピーは保持しません。

承認と移植

承認はユーザーがチャットで明示的に述べることです。承認された提案のパスと、references/compose-mapping.mdが移植テーブルであることを報告します。探索のみのリクエストはそこで終了します。実装は行わないでください。ビルドリクエスト（android-designスキルが新しいアプリ、画面、リデザインのデザイン重視のビルドを最初にここに送信します）は移植に進みます。承認はライブラリバージョンの変更を許可しません。

移植は、リクエスト元のプロジェクトの計画、ブランチ、検証、レビュールールに従います。

1. 移植する画面に対してexport_kotlinを呼び出します。そのKotlinは最初のドラフトであり、完成したコードではありません。
2. references/compose-mapping.mdを使用して、アプリの規約とライブラリバージョンに適合させます。
3. compose-previewスキルで結果をレンダリングし、同じビューで提案のツリーと比較します。

マッピングで未検証とマークされたコンポーネントと、不足しているものを報告します。Compose相当物を独自に作成しないでください。アプリの依存関係でデザインを維持できない場合は、質問してください。

Wear OS

Wearの提案も同じワークフローに従います。android-designのreferences/wear-os.mdがデザインルールを所有し、proposal-format.mdがファイル形式（カタログID、ビュー、Screen、primary、large）を所有します。

• 独自のファイル。 1つの提案につき1つのサーフェス。電話の提案の横にdesign/<slug>-wear.proposal.jsonを作成します。
• 適応チェック: Wearサイズのオーバーライドは225dpから適用されるため、チェックは「両方の時計サイズに収まり読み取れ、大きい方がより多くの値を表示し、決して少なくない」です。
• 共有のDESIGN.md: そのシードとカラーロールはWearに適用されます。タイポグラフィはRoboto Flexに置き換えられます。
• 指摘事項: round-edge-clipped（固定画面上で丸いエッジによってコントロールまたはテキストが切り取られる）を、パーセンテージスタイルのマージンまたはより小さいレイアウトで修正します。
• 移植: 同じ3つのステップ。export_kotlinはWear Composeを記述します。プレビューアーの正確な色を使用したWearAppTheme、AppScaffoldとScreenScaffold、スワイプで閉じるNavigation 3。両方の丸型サイズ（204dpと227dp）で移植をレンダリングします。

削除

ユーザーが要求した場合、design/<slug>.proposal.jsonを削除します。ユーザーが削除を要求しない限り、DESIGN.mdは保持します。