charliesbot/android-design-explore

视觉设计探索

对于每一个设计决策，遵循 android-design 技能：其第 0 部分的答案、组件、主题、布局以及屏幕检查的问题。本技能拥有工作流的所有权。每次运行都是一次性操作：输入简要需求，生成一个提案，检查，展示，然后停止。手机、折叠屏、平板、桌面和 Wear OS 应用屏幕在其范围内；Wear 磁贴、表盘和小组件则不在范围内。当 Wear 存在差异时，下方的 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 尺寸覆盖从 225dp 开始应用，因此检查项为“在两个手表尺寸下都能适配并正常阅读，且大尺寸显示更多价值，绝不能更少”。
• 共享的 DESIGN.md： 其种子色和颜色角色适用于 Wear；其排版由 Roboto Flex 替代。
• 发现： 修复 round-edge-clipped（控件或文本在固定屏幕上被圆角边缘裁剪）问题，方法是使用百分比边距或更小的布局。
• 移植： 相同的三个步骤。export_kotlin 编写 Wear Compose：一个包含预览器精确颜色的 WearAppTheme，AppScaffold 和 ScreenScaffold，以及带滑动返回功能的 Navigation 3。在两个圆形尺寸（204 和 227dp）下渲染移植的端口。

删除

当用户要求时，删除 design/<slug>.proposal.json。除非用户要求，否则保留 DESIGN.md。