charliesbot/android-design-explore

視覺設計探索

每項設計決策皆遵循 android-design 技能：其第 0 節解答、元件、主題、版面配置及畫面檢查提問。此技能擁有工作流程。每次執行為一次性：傳入簡要說明、提出一個提案、檢查、顯示，然後停止。涵蓋手機、摺疊機、平板、桌面電腦及 Wear OS 應用程式畫面；不包含 Wear 圖塊、錶面及小工具。若 Wear OS 有差異，下方 Wear OS 區段會說明。

提案是一個資料檔案，預覽應用程式（原生 macOS 視窗）會使用真實的 Compose Material 3 元件繪製，並在每次儲存時重新繪製。您透過應用程式的佈局樹檢查提案；使用者在視窗中判斷視覺感受。

需求

需要 macOS，且預覽應用程式已安裝並註冊為名為 android_design_preview 的 MCP 伺服器。首先呼叫其 status 工具。若其工具無法使用，請停止並告知使用者以下兩個步驟，然後等待：

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 節。

• 選擇一個種子：品牌顏色，或來自主題的內容顏色（一道菜、一張專輯、一趟旅程），絕不能使用應用程式的預設 #6750A4。
• 當畫面的英雄時刻（第 0 節的問題 3）時，應疊加三種或更多策略（第 3 節）並命名它們。
• 保持應用程式程式碼和相依性不變。
• 使用具代表性、非敏感的資料和素材。僅在提案內使用圖片生成功能，絕不能將其作為提案的替代品。

僅在使用者要求時才製作多個提案。每個提案都是獨立的檔案，是獨特的組合（非重新著色），在其 theme 中有自己的種子，且至少有一個是英雄級。

檔案

在應用程式的儲存庫根目錄或使用者指定的資料夾中工作。切勿寫入此技能本身的儲存庫。

• 根目錄下的 DESIGN.md 存放共享設計系統。若缺少則建立，內容包含選定的種子、字型與命名樣式。僅當方向改變所有提案共享的內容時才修改它；方向的獨特外觀則放入提案的 theme 中。
• design/<slug>.proposal.json 存放一個提案。

兩者皆為普通的追蹤檔案；提交它們遵循專案自身的工作流程。告知使用者提案的絕對路徑。

撰寫

1. 呼叫 get_catalog（其工具說明會回傳內容）。這是唯一的元件詞彙表：缺少的元件無法使用，因此需利用 Box、Row、Column、Text 和 Shape 建構構想，或將其省略。
2. 讀取 references/proposal-format.md，然後緊湊地撰寫 DESIGN.md 和提案，如該文件「緊湊撰寫」一節所述。

提案需遵循以下設計規則；proposal-format.md 提供了每項規則的語法，其元件規則一節則包含分頁標籤、輪播、疊加層、選擇、工具列、選單、應用程式列和徽章的規則：

• 畫面有一個主要操作，標記為主要，並如 android-design 第 2 節所述引導同級操作。
• 在 600 和 840 dp 時進行適配：緊湊模式下的導覽列在中型以上變成側欄，列表的詳細畫面在展開寬度下會顯示在列表旁。
• 文字會刻意截斷，並顯示省略號。按鈕、晶片和導覽標籤的文字應維持單行。

檢查

對於提案，此步驟取代 android-design 畫面檢查中的渲染過程。根據 check_proposal 的佈局摘要和錯誤（若不夠則使用 get_tree）回答其問題，絕不能依賴渲染或像素。螢幕截圖不參與此循環：絕不截取或要求截取。

1. 使用提案的絕對路徑呼叫 open_proposal。它會載入檔案、監視檔案、顯示視窗，並回傳驗證錯誤。修正錯誤並呼叫 status，直到報告無錯誤。
2. 呼叫 check_proposal。一次呼叫會檢查每個視圖中的每個畫面，並回傳每個視圖的錯誤和 layout 摘要；其工具說明會給出格式。
3. 一次修正所有錯誤，然後再次呼叫 check_proposal。overflow 錯誤表示某個節點佈局寬度超過其父容器或視圖（例如需要比其儲存格更多寬度的行）；需縮小、換行或允許其滾動。回報任何仍然失敗的項目，不要重複循環。
4. 從 layout 摘要確認適配：每個較大的視圖都應揭示您在第 0 節適配答案中承諾的內容，例如第二個窗格、側欄或更多區域。Google：「額外空間不僅僅意味著讓同樣的東西變大。」若較大視圖僅是將手機的區域更寬地展開，則表示適配失敗。
5. 僅在摘要或錯誤不足以判斷時才呼叫 get_tree；其工具說明會回傳內容。

當 check_proposal 通過或每個剩餘錯誤都已在您報告的清單中，且適配已確認時，此步驟即完成。

顯示

呼叫 show_preview。用一句話說明提案內容，命名英雄級提案所疊加的策略，列出任何未解決的發現，並報告「視覺品質僅根據佈局樹判斷」。然後停止並等待使用者回覆。

修訂

根據使用者的回饋編輯同一個提案；視窗會在儲存時重新繪製。對已修改的畫面重複檢查步驟。修訂會取代舊版本；不保留副本。

核准與移植

核准由使用者在對話中明確表示。報告已核准提案的路徑，並告知 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）。

• 其專屬檔案。 每個提案一個表面：在手機提案旁撰寫 design/<slug>-wear.proposal.json。
• 適配檢查： Wear 尺寸覆寫從 225 dp 開始生效，因此檢查標準為「在兩種手錶尺寸下都能完整顯示與閱讀，且大尺寸應顯示更多價值，絕不能更少」。
• 共享的 DESIGN.md： 其種子和色彩角色適用於 Wear；其字型則由 Roboto Flex 取代。
• 發現事項： 修正 round-edge-clipped（固定畫面下控制項或文字被圓形邊緣裁切）問題，可使用百分比式邊距或較小的佈局。
• 移植： 相同三個步驟。export_kotlin 會撰寫 Wear Compose：使用預覽器的確切顏色的 WearAppTheme、AppScaffold 和 ScreenScaffold，以及支援滑動關閉的 Navigation 3。以兩種圓形尺寸（204 和 227 dp）渲染移植結果。

刪除

當使用者要求時，移除 design/<slug>.proposal.json。除非使用者要求一併移除，否則保留 DESIGN.md。