mobile-design-system

mobile-design-system：令牌、主题与 SAFE/RISK 提案

一套连贯的系统，先如实提出，再写入实际文件。不包含界面。

流程

1. 探查技术栈 + 阅读应用要点

阅读 package.json / tailwind 配置 / 现有主题文件 / MOBILE-DESIGN.md。 检测样式系统（NativeWind、StyleSheet、Tamagui、Paper）——输出格式 遵循该系统。确定应用类型、受众、平台取向和调节项（每项一行； 若存在 MOBILE-DESIGN.md，则继承其中的信息）。应用类别偏好表 （mobile-taste SKILL.md 1.A2）。

2. SAFE/RISK 提案

将整个系统作为一个整体提出，并明确拆分：

SAFE 选择——用户对该类别应用的预期基线。对大多数应用而言：系统字体、 原生界面元素、克制的中性色阶、符合平台惯例的圆角。明确说明这些为何是安全选择，以及它们在此处是否合适。

风险（至少 2 个，至多 4 个）——刻意偏离基线的选择，每项包含：

RISK: <the move>            e.g. "true-black OLED dark mode as the primary theme"
gain: <what it buys>        "distinctive night identity, battery on OLED"
cost: <what it costs>       "elevation must come from borders, not shadows"

零风险的提案只是模板；全是风险的提案则像是刻意扮演的角色。

一致性验证——如果两个选择相互冲突（紧凑的专业工具布局 + 活泼圆润的字体；按平台区分的设计取向 + 完全自定义的标签栏），用一句话指出冲突并提出解决方案。只指出问题，不要默默“修复”。

提案涵盖：调色板（语义令牌：background、surface、text-primary、 text-muted、accent、border、destructive——同时提供浅色和深色模式的值）， 字体比例（display/title/body/caption + 符合 SKILL.md 6.1 的动态字体大小边界）、间距比例、 圆角比例 + 形状锁定、阴影令牌（iOS 阴影 + Android 仰角配对值）、 图标系列 + 描边粗细、触觉反馈词汇、动效取向（三个调节项的影响）以及标志性元素预算。

继承 mobile-taste 6.2 的硬性规则：一个强调色；一个灰色系列；不使用靛蓝色流水线；默认饱和度 < 80%；从第一天起支持两种模式；只有在明确声明为刻意选择时才允许使用 OLED 纯黑。

3. 预览（可选，只提供一次）

提供独立的 HTML 样例——单个文件，不发送外部请求：以色块展示调色板（含两种模式，可切换）、使用实际字体（系统字体或声明的字体）呈现字体比例，并在模拟组件上展示圆角/阴影样例。在本地打开。这是无需工具的路径，也是首选路径；不要依赖图像生成或外部二进制文件。

4. 写入实际文件

根据探查到的技术栈：

• NativeWind： tailwind.config 主题扩展 + theme/tokens.ts（如果项目使用 CSS 变量主题，则加入 vars() 接线）+ 深色模式值。
• StyleSheet： theme/tokens.ts，包含带类型的颜色/字体/间距/圆角/阴影对象，以及遵循 useColorScheme 的 useTheme() hook。
• 已有令牌文件： 扩展该文件；重命名现有令牌名称属于严禁静默变更的事项（../_shared/references/redesign-protocol.md）。

5. 保存到 MOBILE-DESIGN.md

写入（或更新，并报告差异）## Design System 部分：已批准的提案、RISK 登记表，以及令牌文件所在位置。后续会话和同级技能会在做出任何界面决策前读取此部分。

对此技能有约束力的规则

• 只提出一次，保持一致——不要列出五套调色板供人选择。一套明确标注风险的系统胜过情绪板。
• 写入文件的每个值都必须能追溯到已批准的提案。不得夹带额外令牌。
• 如果用户否决某项 RISK，就用 SAFE 版本替换，并在 MOBILE-DESIGN.md 中注明此项调整；不要悄悄保留原选择。