to-design-brief

本技能读取两份输入——设计语言文档（含 colors / typography / rounded / spacing / components token 的分析文档，如 DESIGN-linear.md）与 PRD——合成一份 design brief。brief 的读者是 Claude Design 或 OMP 中的设计 agent：它们不应依赖未显式提供的本地上下文，因此 brief 必须自包含，单独交付即可作为后续逐页生成的风格锚点。

输出格式与逐节写法见 BRIEF-FORMAT.md，写作前先完整读取。

输入与决策

1. 定位输入文件。 用户未给路径时先在对话上下文中找；找不到再问。设计语言文档通常带 token frontmatter；PRD 通常带需求编号（如 REQ-xx）。两份都要完整读取，不要只读开头。
2. 确认设计语言。 同目录存在多份设计语言文档（如 DESIGN-linear.md / DESIGN-stripe.md）且用户未指定时，列出各自气质摘要请用户选择。风格是产品决策，不要代替用户选。
3. 确认主题明暗。 设计语言文档多来自营销站分析，其主题（常为深色）不一定适合目标产品。优先级：用户指定 > PRD 约定 > 沿用设计文档原主题并在 brief 顶部标注「沿用原主题，如需反转请告知」。需要反转明暗时，保留色相与气质（强调色、圆角、边框哲学不变），重新推导中性色阶与语义映射。
4. 确认输出路径。 用户未指定时写到 PRD 同目录的 design-brief.md；目标文件已存在时先读取，向用户确认覆盖或另存。

合成流程

1. 从 PRD 提炼产品骨架：产品定位（一句话说清是什么、不是什么）、端口与最小视口、界面语言、账号/权限体系中影响界面的部分、页面清单。页面清单按 PRD 模块划分，每页标注覆盖的需求编号；纯非功能需求（如数据脱敏）不单列页面，转写为对应页面的设计约束。
2. 从设计语言文档转译 token：营销站 token 要转成产品界面可用的两层结构——原始色板 + 语义映射层（背景/文字/边框/状态），brief 中只允许语义层被页面规格引用。原文档缺少后台必需的语义色（成功/警告/危险/信息）时，按原文档色彩气质补齐，并标注哪些是推导新增。字体、圆角、间距、阴影直接沿用原 token，只做取舍不做发明；保留原文档的层次哲学（如「发丝边框优先于阴影」）。
3. 推导组件规范：从 token 推导目标产品需要的组件清单（后台类产品通常是：侧边导航、顶栏、按钮组、输入框、表格、状态标签、指标卡、Tabs、面包屑、布局骨架）。每个组件写明引用的语义 token 与关键尺寸，不贴实现代码。
4. 写逐页规格：每页列出主区内容结构、用到的组件、关键交互态（空态/加载/错误/权限不足，PRD 有定义才写）。规格描述内容与结构，不重复设计系统里已定的视觉细节。
5. 写使用说明与生成顺序：brief 开头写明粘贴用法与逐页指令模板；结尾给出建议出图顺序（先设计系统预览页校准风格，再做骨架页，最后批量出剩余页面）。

校验

发布前逐项确认：

• PRD 中每个需求编号都能在某页规格或设计约束中找到，遗漏的补上；确实不影响界面的，在 brief 末尾注明「不体现于界面」。
• brief 中每个色值、字号、圆角都能追溯到设计语言文档或已标注的推导新增，不存在两处矛盾的取值。
• brief 不引用任何本地文件路径或对话上下文，整段粘贴后信息完整。
• 篇幅控制在一次粘贴可用的范围（正文约 300 行以内）；超出时优先压缩逐页规格的重复描述，而不是删减设计系统。