ultrahand: 移动端 UI 设计

将手机屏幕设计成一个交互式 Claude Artifact，可在三种手机尺寸的竖屏和横屏之间切换。你应用的所有规则均位于 references/principles.md 中，每条规则都引用了 references/sources.md。尺寸和安全区域位于 references/presets.md 中。

1. 收集需求

只询问你无法推断的内容。绘图前先确定以下事项：

平台： iOS、Android 或两者兼顾。如果两者兼顾，使用 48 单位触控目标和平台无关的模式。
范围： 单个屏幕或一个流程。对于流程，列出所有屏幕以及用户如何在它们之间移动：标签页切换、导航推送、表单呈现或全屏模态。
主要任务： 每个屏幕的唯一用途。该操作应置于拇指可达范围内。
真实内容： 名称、长度、数量和最长的合理字符串。不要用 lorem ipsum 进行设计。
数据状态： 加载什么、什么可以为空、什么可能失败或离线。
约束： 品牌颜色、字体、现有的设计系统，以及它是原生应用还是 Web。
主题： 在选择任何颜色、尺寸或间距之前，先查找项目主题（design/THEME.md、*.tokens.json；参见 shared/theme/README.md）。如果有主题，请使用它进行设计：运行 node "${CLAUDE_PLUGIN_ROOT}/shared/theme/css.mjs" <tokens.json> --style --out theme.html，将 --head theme.html 传递给构建脚本，仅使用其自定义属性（var(--color-surface)、var(--space-gap-group)），并复用其清单中的组件。当设计需要主题中缺少的东西时，使用最接近的标记，并将添加的内容列在开放问题中；不要自己发明数值。如果没有主题，则遵循 shared/theme/rules.md 中的强制性规则，并提供 theme 技能。

2. 阅读参考资料

在设计之前，阅读 references/principles.md 和 references/presets.md。使用平台自身的模式（标签栏、导航堆栈、表单），而不是发明新的模式。

3. 组合屏幕

即使每个组件都通过各自的检查，它们组合起来也可能导致屏幕混乱。在开始构建之前，规划它们如何形成区块，以及区块如何形成屏幕，使用插件的组合规则，位于 shared/composition/principles.md：

编写区块映射。 对于每个屏幕，列出其区块（导航栏、内容、主要操作和标签栏），每个区块的单一职责，其成员按使用频率排序，以及它的一个强调重点。说明哪些是主要内容，哪些是界面装饰：内容占主导，装饰应退让。
用间距分组。 组内间距明显小于组间间距；只有当间距不足以显示分组时，才添加容器。
同角色同样式，每区块一强调。 相同角色，相同样式；状态和标签永远不应看起来像按钮；每个区块中强强调色只应用于一个元素，选中状态使用更安静的处理方式。
保持精简。 大约三种字号，每个信息只出现在一个地方，频繁使用的成员保持可见，不常用的成员放在菜单后面。当一次更改添加了内容时，先重新组织，只添加那些能证明其存在必要性的内容。

4. 构建画布 artifact

基于插件的共享可调整大小画布构建（shared/canvas/；其 README.md 包含完整约定）。将屏幕编写为 screen.html，将设计自身的设置编写为工作文件夹中的 config.json，然后构建：

node "${CLAUDE_PLUGIN_ROOT}/shared/canvas/build.mjs" \
  --presets "${CLAUDE_PLUGIN_ROOT}/skills/mobile/references/presets.md" \
  --config config.json --screen screen.html \
  --title "<设计名称>" --out index.html

将 index.html 发布为 artifact。预设为 small 360 (Android)、medium 393 和 large 430 (iOS)；旋转可显示每个尺寸的横屏，320 宽度的回流检查位于“检查”下方。

config.json 设置 title 和 states（例如 default、loading、empty、error）。对于仅 iOS 的设计，设置 "initialPreset": "medium"；对于 iOS 和 Android 同时支持的设计，设置 "minTarget": 48，以便每个预设都按照更严格的目标进行衡量。
屏幕约定： 一个 <template id="uh-screen">，包含带有 [data-screen] 属性的区块，以及用于点击的 data-nav、data-nav-replace（标签页）、data-nav-back 和 data-show-state。边缘内边距使用 var(--uh-safe-top|right|bottom|left)，这些变量遵循预设及其旋转；在 [data-screen] 上声明使用这些变量的标记，因为 :host 无法识别它们。使用 @container screen (width >= …) 响应尺寸变化，而不是 @media。文本使用 rem；点击区域、图标和间距使用 px，这样 200% 文本缩放只会放大文字，而不会放大控件。颜色使用 light-dark()。行为放置在 window.ultrahandSetup = function (canvas) { … } 中。
粘性部分： 将所有固定在底部的元素（标签栏、FAB、Snackbar）堆叠在一个容器中，以避免重叠，并在 [data-screen] 上设置 scroll-padding，以便焦点滚动时能避开粘性条 [WCAG-2.4.11]。在高度紧凑或 200% 文本缩放时，让页眉变为静态 [WCAG-1.4.4]。
每个预设的平台： small 是 Android，medium 和 large 是 iOS。在存在差异的约定（如返回控件、标题对齐和触控目标尺寸）上，遵循 canvas.size.platform。
内置切换： 浅色/深色模式、200% 文本缩放、状态选择器和显示触控目标（44 pt，或 Android 预设上为 48 dp）。不要自己构建这些功能。在打开表单后调用 canvas.refresh()，以便目标覆盖层能看到它。
使用弹性单位和内边距进行布局，而不是固定的设备数字，这样一套设计就能适应所有预设。
使主要流程可点击：标签页切换、行推送、表单打开和关闭。在屏幕中绘制表单和对话框；永远不要使用 alert、confirm 或 prompt。

5. 设计每个预设

对于每个屏幕，依次处理 small、medium、large，然后是每个尺寸的横屏。在问题出现的尺寸上修复它：

small (360)： 文本和按钮仍能容纳，且不截断关键信息。
large (430)： 内容不会拉伸成很长的行，也不会留下死空间。
横屏： 在高度较矮的情况下，聚焦的字段仍能显示在键盘上方，并且尊重侧面安全区域。同时使用 200% 文本缩放进行检查：粘性页眉和底部容器加起来必须为内容留出大部分屏幕空间。

然后快速检查 320 宽度的回流。

6. 展示前自检

逐项检查。修复所有失败项，或者指出问题并说明为何可接受。

组合（运行组合审核，node "${CLAUDE_PLUGIN_ROOT}/shared/input/drive.mjs" do "${CLAUDE_PLUGIN_ROOT}/shared/composition/audit.mjs"，在最大和最小尺寸下进行检查，或目测核对）：

模糊后，屏幕显示出预期的区块，主要内容首先吸引眼球。没有意外的亮斑。
每个区块有一个职责，其成员按功能和频率分组，组间间距明显大于组内间距。
每个区块最多有一个强烈强调的元素；选中状态是安静的。
同角色同样式：计算每个区块中的控件样式，并证明任何额外的样式是合理的。没有标签或状态看起来像按钮。
行和区块与共享的边缘对齐；屏幕上大约使用三种字号。
没有重复显示的信息，屏幕上没有服务于当前任务以外的元素。
经过一轮更改后：列出添加的内容；屏幕不比必要的更忙乱。
仅使用主题值：无原始颜色，无偏离 8 点网格的间距，无超出字阶的字号，并且复用了清单中的组件而非重建。（shared/theme/rules.md NN-1、NN-2、NN-6、EV-4）。

组件与平台：

7. 展示

分享 artifact 链接。用几句话说明区块映射（每个区块的职责和强调重点）、关键决策及其背后的原则（引用来源键）、你接受并给出理由的自检项、任何提议的主题添加项（供 theme 技能使用）以及任何开放问题。

移动端 UI 设计